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Preface 


The following document is the culmination of the work performed by a team of 
eight graduate engineering students assigned to the Air Force Institute of Technology 
(AFIT). The students compiled this document while performing a systems engineering 
design study to create a small standardized tactical satellite bus for the Phillips 
Laboratory. This document is divided into three separate volumes. Each volume is an 
integrated element of the student thesis but it can also serve as a stand alone document. 

The first volume is the Executive Summary. The purpose of the Executive 
Summary is to present a synopsis of the design study results to the sponsor at the Phillips 
Laboratory. This volume includes information on the methods employed during the study, 
the scope of the problem, the value system used to evaluate alternatives, tradeoff studies 
performed, modeling tools utilized to create and analyze design alternatives, 
recommendations and implications of the alternatives, and areas where future research 
should be considered. 

The second volume is a detailed account of the design process. The steps of the 
team’s innovative design process and the team organization are initially presented. Each 
phase of the design study is discussed in subsequent sections. Phase I provides accounts 
of the team’s initial attempt to apply a well known systematic approach to satellite design. 
Efforts concentrate on defining the problem posed by the sponsor. “First cuts” at 
developing analysis tools and models are performed. Additionally, different alternatives 
are generated as possible solutions to the problem. An initial analysis and evaluation is 
performed to define an initial solution space, and to verify the analysis tool. Phase II is an 
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iterative step in the design process and serves as a reservoir for the team’s most 
meaningful work. The team realized that a new systematic approach had to be applied to 
the study. This phase provides the results of the application of that innovative approach. 

It is here that the understanding of the problem is further refined and decisions are made 
that limit the scope of the study. The objective hierarchy is further developed and a value 
system is created as a method for measuring each design alternative. Information is 
collected on satellite designs and satellite subsystems. Tradeoffs are performed to 
determined the best methods and components to be used in the alternatives. A model is 
created and design alternatives are generated. System analysis is performed on the 
alternatives using the value hierarchy, and results are generated. Sensitivity analysis is 
performed on the alternatives, and implementation recommendations are provided to the 
sponsor. 

The third volume provides details on the tools developed to build a satellite and to 
analyze the design. There are three sections to this volume. The first section describes the 
model’s philosophy and presents details on the purpose and operation of each module of 
the model. Mathematical formulae and module architecture are also described in this 
section. The second section is a user’s guide to operating the model. Specific details of 
the sequence to be used and information required to run the model are provided in this 
discussion. The final section of this volume is the actual code of the model. The code is 
contained in an annex and is maintained by AFIT’s Aeronautics Department at Wright- 
Patterson AFB, Ohio. The code can be provided to allow future modelers to understand 
and refine the work that has been accomplished. 
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Abstract 

A PRELIMINARY DESIGN OF A STANDARDIZED SPACECRAFT BUS FOR 

SMALL TACTICAL SATELLITES 

Current satellite design philosophies concentrate on optimizing and tailoring a particular 
satellite bus to a specific payload or mission. Today's satellites take a long time to build, 
checkout, and launch. Space Operations planners, concerned with the unpredictable 
nature of the global demands placed upon space systems, desire responsive satellite 
systems that are multi-mission capable, easily and inexpensively produced, smoothly 
integrated, and rapidly launched. This emphasis shifts the design paradigm to one that 
focuses on access to space, enabling tactical deployment on demand and the capability to 
put current payload technology into orbit, versus several years by today's standards, by 
which time the technology is already obsolete. This design study applied systems 
engineering methods to create a satellite bus architecture that can accommodate a range of 
remote sensing mission modules. System-level and subsystem-level tradeoffs provided 
standard components and satellite structures, and an iterative design approach provided 
candidate designs constructed with those components. A cost and reliability trade study 
provided initial estimates for satellite performance. Modeling and analysis based upon the 
Sponsor’s objectives converged the designs to an optimum solution. Optimum design 
characteristics include a single-string architecture, modular solar arrays, an internet-style 
command and data handling system, on-board propulsion, and a cage structure with a 
removable frame for easy access to subsystem components. Major products of this study 
include not only a preliminary satellite design to meet the sponsor’s needs, but also a 
software modeling and analysis tool for satellite design, integration, and test. Finally, the 
report provides an initial implementation scheme and concept for operations for the 
tactical support of this satellite system. 
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1. Report Overview 


This document provides the results of a group design study performed at the Air 
Force Institute of Technology. The team of eight graduate engineering students examined 
the design of a generic satellite bus for small tactical satellite applications. The project was 
sponsored by LtCol James Rooney of the United States Air Force’s Phillips Laboratory in 
Albuquerque, New Mexico. Similar design studies have been completed by various 
companies and laboratories, but to date success has been limited. Phillips Laboratory’s 
goal was to seek a “clean-sheet” approach to the design of a cost-effective satellite bus. 
Several design characteristics were suggested by the sponsor and were considered 
throughout the project. These characteristics included modularity, flexibility, robustness, 
and operability. These characteristics have been treated as guidance in developing 
objectives and alternative design architectures and were not treated as hard requirements. 

This is the first volume of a three volume report. Volume I is an Executive 
Summary of the work performed by the design team. Volume II provides greater detail of 
the work and includes the theory and analysis behind the team’s approach to the problem. 
Volume III is an in-depth explanation of the modeling performed for the project and 
includes the associated code. 

This volume provides a high level discussion of the results of the team’s efforts. 
The first section discusses the design process that evolved during this study. The 
remaining sections document the results in each of the steps of the systematic process. 
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A majority of the work was performed in the second iteration of the design study. 
This volume presents this information and contains a discussion on the scope of the 
problem, the value system design, the decisions made in the tradeoffs section, and an 
overview of the modeling efforts. Different design alternatives are presented in system 
synthesis and the analysis of the alternatives are documented in the system analysis 
section. Sensitivity analysis is included as part of decision making and the implementation 
plan discusses how the selected alternative can be integrated into space operations. The 
final section of this report provides a discussion on future technologies and areas where 
further research can enhance the products of this study. 
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2. Design Process 


The design team recognized the need for a well-defined, iterative, systematic 
design process to approach the problem logically. The design team was familiar with two 
well-known systematic approaches, Hall’s seven-step process to systems engineering 
(Hall, 1969:156) and the space mission design approach described in the Space Mission 
Analysis and Design (SMAD) textbook (Wertz and Larson, 1992:1). 

Hall’s systematic process has been a standard systematic approach for almost four 
decades. This process is well understood and can be applied to many different engineering 
problems. The Hall method is an iterative seven-step process (refer to Figure 2-1). These 
steps are: problem definition, value system design, system synthesis, system analysis, 
optimization, decision-making and implementation (Hall, 1969:157). 



Figure 2-1: Hall's Seven-step Approach 












Each step of Hall’s approach is influenced by the actions taken in the other steps. 
The process’ iterative nature forces refinement in each step as the process continues. 
Hall’s fundamental framework follows a logical sequence that allows the user to define 
and constrain the problem, create an evaluation tool using the decision-maker’s values, 
and generate possible solution alternatives. The framework also permits the user to create 
models and perform simulations as a means of quantifying aspects for each alternative. 

The quantified values serve as an input into the evaluation tool. Once the basic modeling 
is accomplished, different aspects of each possible solution are further refined in an 
attempt to optimize each alternative. Hall’s process also allows the user to perform 
sensitivity analysis on each of the alternatives before the decision-maker is presented with 
the results of the system evaluation. In the decision-making step, the decision-maker 
applies his subjective values and risk preferences to select an alternative. With an 
alternative selected, a plan for implementation is created. The Hall process is complete 
once an adequate implementation strategy is accepted by the decision-maker. 

The SMAD approach is well-known to contemporary satellite designers (Warner, 
1996). The SMAD text and the process it describes is a compilation of the first thirty 
years of satellite design experience. In general terms, the SMAD process can be 
considered the classic approach to satellite design because the approach is based on the 
premise that the satellite’s mission drives the design of the satellite bus. The SMAD 
approach is iterative and consists of four broad areas. These broad areas are 1) define 
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objectives, 2) characterize the mission, 3) evaluate the mission, and 4) define requirements 
(Wertz and Larson, 1992:2). 


Table 2-1: Space Mission Analysis and Design Process 



Define Objectives 



Sub-steps 


I A. Define broad objectives and constraints 
i B. Estimate quantitative mission needs and requirements 


Characterize the Mission 

C. Define alternative mission concepts 

D. Define alternative mission architectures 

E. Identify system drivers for each 

F. Characterize mission concepts and architectures 

Evaluate the Mission 

: 

G. Identify driving requirements 

H. Evaluate mission utility 

I. Define mission concept (baseline) 

Define Requirements 

J. Define system requirements 

K. Alocate requirements to system elements 


The first step in the SMAD process is to define the broad mission objectives and 
constraints. Additionally, quantified estimates of how well one wants to achieve the broad 
mission objectives are developed with respect to the needs, constraints, and technology 
available. These estimates become initial system requirements. A unique feature of the 
SMAD process is that these quantified estimates are subject to trades as the process 
continues. Characterizing the mission involves a number of steps. These steps include 
defining alternative mission concepts and architectures, identifying system drivers for each 
alternative, and describing in detail what the system is and what it does. Power, weight, 
and pointing budgets are developed in this step. Evaluating the mission forces the 
designer to return to the initial system requirements to determine which requirements 
become driving requirements. Driving requirements are the items principally responsible 
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for determining the cost and level of complexity of the system. Mission utility analysis is 
also part of this step and this analysis quantifies how well the satellite design meets the 
system requirements and objectives as a function of design choices. Evaluation of the 
mission ends by choosing a baseline system design. The SMAD process ends by defining 
requirements. Broad objectives and constraints are translated into well-defined, specific 
system requirements. These numerical requirements are allocated to specific components 
of the overall space mission (Wertz and Larson, 1992:3-90). 

The traditional approaches are not suited to designing a satellite bus that will 
support a variety of missions. This was recognized as the study evolved and initial 
iterations of the applied processes failed to narrow the scope of the study. Specifically, 
Hall’s approach does not provide an effective, streamlined method for converging on 
viable satellite design alternatives, Time is wasted performing numerous iterations of the 
process to achieve the desired focus. Likewise, the SMAD process concentrates too 
much on using the satellite’s payload (mission module) as the key upon which the satellite 
bus is designed. Consequently, neither of these methods is adequate for designing a 
generic, standardized satellite bus. A new, customized approach was developed that 
permitted the team to converge quickly on a satellite bus design without regard to a 
particular mission module type. The systematic process that was created is a synthesis of 
the methods described by Hall and SMAD. The process is called the Modsat approach. 
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Table 2-2: Modsat Systems Approach 


Step 


|t§§ 

Action | 

Problem Definition 

Scope nature of problem 1 

Value System Design 

Capture decision maker’s needs and goals; create j 

evaluation structure for alternatives 

Trade Studies 

Link broad design decisions directly to the study’s 
goals and objectives 

Modeling 

j. 

Formulate predictive or descriptive tool(s) to 
represent activities; analyze various configurations 

System Synthesis 

Create alternative solution sets 

! System Analysis 

Score each alternative against problem’s evaluation 
structure 

Decision Making 

Perform sensitivity analysis on solution sets 

Implementation 

Develop plans for fielding the selected altemative(s) 


The iterative approach is comprised of eight steps. The steps, in order, are 
problem definition, value system design, trade studies, modeling, system synthesis, systems 
analysis, decision-making, and implementation. The majority of these come directly from 
Hall’s seven-step process. The items that distinguish this approach from Hall’s approach 
are the inclusion of a trade studies step and the reordering of the system synthesis and 
modeling steps. Additionally, the design team’s approach does not include an 
optimization step. This process distinguishes itself from the SMAD process in two ways. 
The systematic approach does not commit its focus to the requirements of one mission 
module as the key factor for satellite bus design. Secondly, the process specifically 
includes a method for evaluating the merits of each design alternative. 

Problem definition is a fundamental first step of any systematic process. The 
Modsat problem definition step closely follows that of Hall. The purpose of this step is to 
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define and constrain the problem. A result of this step is a succinct statement that 
identifies the goal and focus of the study. The value of the problem definition step is that 
it serves as a mechanism to define the system boundaries, identify the system needs, 
alterables and constraints, and to identify the system actors. 

The system boundaries define the environment affecting the system. A distinction 
can be made between those items contained within an internal environment and those 
items contained in the external environment. Items within the internal environment are 
factors that the design team can control. Items that exist in the external environment 
influence the study but cannot be controlled by the design team. The distinction between 
the internal and external environment is paramount to understanding the scope and focus 
of the project. The focus of the study can be narrowed further by performing iterations on 
the system boundaries. Needs are the fundamental requirements that the decision-maker 
and users levy on the system and are crucial in determining the broad objective of the 
study. As is the case in the SMAD process, some needs serve as driving requirements for 
satellite bus designs. Other needs may be traded off against each other. Alterables are 
those items that can be influenced or changed by the design team and are contained within 
the internal environment of the system’s boundaries. Constraints are those items that the 
team cannot control but have a major impact on focusing the study. Problem definition 
also identifies the actors in the study. Actors are simply the persons/groups who influence 
the design and evaluation of possible alternatives. Different tools such as concept maps. 
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waterfall diagrams, and interaction matrices can be used to assist in defining the system 
boundaries, needs, alterables, constraints, and actors. 

The value system design step is similar to Hall’s respective step. The purpose of 
this step is to capture the decision-maker’s values and goals. Ultimately, these values and 
goals are used as a means for evaluating the effectiveness of design alternatives. 

Capturing the decision-maker’s values and goals is accomplished by creating an objective 
hierarchy. Broad values and goals are translated into broad objectives. The broad 
objectives are decomposed into more specific subobjectives until meaningful measures of 
effectiveness can be determined. The study’s objectives and subobjectives are related to 
the needs, alterables, and constraints defined in the previous step. As part of defining the 
study’s objectives and measures of effectiveness, major premises and assumptions are 
explicitly articulated. 

Once the objective hierarchy is in place the decision-maker’s preferences for each 
objective have to be incorporated into the structure. It is common to have competing 
objectives for a problem or study. A score, or weight, is assigned to each objective per 
level in the hierarchy to capture the importance the decision-maker places on a particular 
objective. The weights are normalized and the resulting weighted objective hierarchy 
eventually serves as the evaluation structure for each solution alternative generated in the 
problem. 

The trade studies step is a new and innovative step. This step evolved out of the 
SMAD process. The purpose of the trade studies step is to make broad design decisions 
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that can be directly linked to the study’s goals and objectives. The emphasis is on 
decisions which can be made without having detailed descriptions of the alternatives. 
Trade studies serve as an efficient and effective means to narrow the study’s scope and 
provide clearer focus early in the design process. The step is efficient because a 
manageable study focus can be reached without the need for extra iterations of the 
process. The step is effective because it reduces the number of possible design 
alternatives that would have to be evaluated to determine a solution to the study. 

The trade studies occur on two levels: the system level and the subsystem level. 
Trades performed on the system level have broader effects on the design of a satellite bus. 
These system level trades add definition to the external environment by providing 
constraints on the system’s boundaries. System level trade decisions also impact the 
trades performed on the subsystem level. 

A satellite bus is a system comprised of smaller subsystems. Each subsystem can 
be designed in a variety of configurations using different qualities and types of 
components. Some choices can be made independent of choices in other subsystems. A 
subsystem design decision that is traceable to the study’s goals and objectives increases 
the possibility that system design alternatives will meet the goals of the study. Defining a 
subsystem configuration or specifying a particular quality or type of component reduces 
the number of iterations a designer may have to perform to create a viable design 
alternative. An additional benefit of including a trade studies step early in the process is 
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that it forces team members to focus efforts on gaining insight into subsystem design while 
simultaneously refining the problem. 

Although the trade studies step evolved from SMAD, it differs from the SMAD 
process in two ways. System level trades in SMAD occur late in the process (the 
“evaluate the mission” step). This results in the study’s focus and system boundaries not 
being fully defined until late in the process. Subsequently, time is wasted early in the 
process by identifying the principal cost and performance drivers for each mission concept 
and mission architectures alternative before the system’s boundaries are defined. 

Secondly, SMAD does not specifically mention that subsystem level trades would occur in 
the process. It can be inferred that the subsystem level trades would occur after the 
baseline concept is determined. 

The next step in the approach is modeling. Modeling is the development of a 
descriptive or predictive model representing a set of activities or the entire system in order 
to allow analysis of alternative configurations of the system (Mosard, 1982:86). The 
modeling step precedes the system synthesis step, unlike Hall’s traditional approach. This 
reordering of process steps is because the creation and development of satellite bus design 
alternatives is tedious and complex. Satellite design is an art because many satellite 
components have to be strategically placed within the confines of a satellite structure to 
meet stringent heat dissipation, thermal shielding, center of mass, volume, mass, and size 
constraints. Modeling provides a tool that permits the three-dimensional visualization of 
the placement and performance of components. Components can be placed, moved, and 
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resized quite easily using a model when compared to physically connecting, disconnecting, 
or replacing components on an actual satellite. Time and cost savings can be easily 
realized through the use of a model, especially if design requirements or assumptions 
change. 

In addition, the model builder can take advantage of the decisions that have 
already been accomplished during the process. Desired subsystem configurations and 
component selection from the trade studies step can be easily loaded into the model before 
alternatives are created. If component selection changes, the new information can be 
easily loaded into the model. Modeling must also be able to quantify the performance 
characteristics of each design alternative. Different subsystem characteristics can be 
emulated using mathematical models that can be programmed into the tool. The team’s 
modeling section currently uses the first order estimates and relationships that are found in 
the SMAD process. Refinements to these relationships can be loaded into the model as 
the design develops. As a minimum, the quantified performance values must be those 
values necessary for input into the value system’s measures of effectiveness. 

The model must allow analysis of alternative configurations of the system. The 
evaluation structure developed in the value system design is incorporated into this stage of 
the process. This puts an evaluation structure in place before any design alternatives are 
generated. With effective use of the modeling tool, it is possible to create new designs 
and perform evaluation on those designs in a timely fashion. 
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The system synthesis step is similar to most systematic approach steps for creating 
alternatives. Accordingly, alternatives can be existing designs, modifications to existing 
designs, prepackaged designs, or entirely new designs (Pohl, 1995). The difference 
between the system synthesis step and traditional steps is its placement after the modeling 
step, for the reasons discussed above. 

The systems analysis step follows system synthesis. The purpose of systems 
analysis is to score each of the design alternatives against the problem’s evaluation 
structure. The problem has been defined and the weighted objective hierarchy is in place. 
Each alternative’s input to the objective hierarchy’s measures of effectiveness is evaluated 
and each solution alternative receives a score commensurate with its performance to the 
competing objectives. 

Decision-making is a step that permits the team to perform sensitivity analysis on 
the design alternatives. Sensitivity analysis is performed by varying one variable at a time. 
This variable is usually a weight associated with an objective in the objective hierarchy. 
The results of the sensitivity analysis provide insight as to how an alternative will perform 
given different preferences of the decision-maker. Including the sensitivity analysis results 
allows the decision-maker to make a subjective decision as to which design alternative will 
meet the goals of the study. 

Implementation is the final step of the systematic approach. The purpose of this 
step is to develop plans for fielding the selected alternative. The plan is presented to the 
decision-maker and reflects the team’s view on how the alternative can be best put to use 
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in the operational setting. It provides recommendations for improvements to the selected 
alternative and to the associated elements that affect the alternative. The implementation 
step also addresses the possible architectures in which the alternative can be deployed and 
it covers the organizational structure necessary to support that architecture. 

The approach described above is an innovative approach to satellite bus design. It 
provides a logical sequence which deliberately allows the design to evolve from one stage 
to another while documenting the decisions and assumptions made along the way. The 
method permits continual improvements to the design as the design matures. This 
approach provides a method for determining if a design alternative is the best design 
possible by incorporating design decisions made throughout the process. The systematic 
approach used in this design study provides a holistic view of the problem and allows the 
team to capture all important aspects affecting the design. This iterative, systematic 
approach ensures that these aspects are correctly integrated throughout the design 
process. 
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3. Team Organization 


This combined approach permitted the team to be easily divided into major areas 
of responsibility within a matrix organization. The team concentrated on three areas: the 
major steps of the combined Hall/SMAD systematic approach, particular satellite 
subsystems, and specific areas of research. Each team member’s responsibility included 
taking the lead in charting the group’s direction for the steps of the Hall/SMAD (reference 
Table 3-1) while maintaining a focus on the team’s limited time, resources, and budget. 
Decisions made in one area of the design or a step in the process had to be properly 
documented and presented to the group to prevent conflicts between satellite subsystems 
and maintain the direction of the project. Team members also provided the group with the 
information necessary to understand each satellite subsystem and to realize the influence 
and impact each subsystem had on the other. The subsystem assignments are listed in 
Table 3-2. Each member also made contacts with aerospace companies or organizations 
that had been involved with the development of satellites within the project’s weight class 
(see Table 3-3). Extremely valuable information was gained by examining the successes 
and failures of other organizations. The following three tables depict the structure of the 
team’s matrix organization. 
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Table 3-1: System Steps Responsibility Matrix 



BSaSSBHIBHHI 

Problem Definition 

From/Krueger 

Value System Design 

Cokuysal 

Trade Studies 

All 

Modeling/Analysis 

Cameal/Ashby 

System Synthesis 

Buck 

Systems Analysis 

Cameal/Ashby 

Decision Making 

Donmez 

Implementation 

Donmez 


NOTE. Robinson served as a “floater” throughout the Hall/SMAD approach. 


Table 3-2: Subsystem Expertise Responsibility Matrix 


Subsystem Area 

BSISMSSBBMM— 

Structures/Mechanisms 

and Thermal Control 

Ashby 

Electrical Power Generation and 

Distribution 

Krueger 

Attitude Determination and Control 

Robinson 

Propulsion 

Cokuysal 

Telemetry, Tracking, and 

Commanding/Data Handling 

Carneal/From 

Mission Modules 

Buck 

Launch Systems/Command, Control and 
Communications/Operations Concepts 

Donmez 
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Table 3-3: Similar Projects Research Responsibility 


Research Area 

ESSBBHBH 

Spectrum Astro/MSTI 

Cokuysal 

TRW and CTA/STEP 

Ashby 

Lockheed-Martin/Iridium 

Carneal 

Orbital Sciences Corporation/Pegasus 

Donmez 

AeroAstro/HETE 

From 

Ball Aerospace 

Buck 

Naval Research Laboratory\Clementine 

Robinson 

Phillips Laboratory/MightySat 

Krueger 
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4. Problem Definition 


4.1 Definition 

Problem definition was the first step of the systematic approached. The purpose of 
the problem definition step was to evaluate the proposed problem and establish a succinct 
problem statement. Defining the problem required careful examination of the sponsor’s 
tasking statement and the factors influencing the proposed problem. Identification of the 
system’s boundary, needs, alterables, constraints, and actors were important to 

understanding the scope of the problem. 

/ 

The system’s boundary defined those elements of the problem, and its potential 
solution space, that could or could not be controlled or manipulated by the design team 
(Athey, 1992:13). Through careful examination and identification of the problem’s 
boundary, the design team determined the factors that influence and affected the problem. 

Needs were the driving factors behind the existence of the problem. Needs were 
referred to as requirements. Without the needs, there would have been no problem. By 
identifying the needs of the chief decision maker (CDM), the team understood why the 
problem existed, what the problem was, and what some of the possible solutions to the 
problem were. Needs also served as a means for measuring the success of potential 
solutions. 

Alterables were those factors the CDM had control over. Identifying those factors 
provided the team with a method of opening the potential solution space to the problem. 
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Constraints, on the other hand, were factors that the CDM and design team had no control 
over. These factors limited the number of potential solutions to the problem. 

Actors were the people who had an influence on the problem and the possible 
alternatives. The most influential actor was the chief decision maker. Capturing and 
incorporating the decision maker’s needs, values, and constraints was paramount to 
producing the best solution possible. The decision maker provided information necessary 
to determine the framework by which all possible alternatives were measured. 

Gaining insight into satellite design and probing the different aspects of the 
proposed problem were the main focus of the first iteration. In the second iteration, the 
team focused its effort on studying and understanding the functions of the satellite 
subsystems and examining the factors that influence the satellite bus design. This led to a 
more detailed examination of the tasking statement and the factors that influence the 
problem. 

The resulting problem statement was referred to throughout the design process. 
This ensured that the team’s efforts remained focused. 

4.2 Problem Statement 

The problem statement reads: 

Design a rapidly deployable, tactically oriented, satellite bus to enhance theater 
operations. This satellite bus is to support missions in the Pegasus and Lockheed-Martin 
Launch Vehicle (LMLV) weight class. 
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4.3 Concept Map 


A concept map was employed to help define the problem. The concept map 
provided a graphic representation of the design team’s interpretation of the problem. 
Concept mapping is based on the premise that all knowledge can be represented by 
relationships between more fundamental concepts (Kramer, 1990:652-654), The concept 
map consists of two primitives: concepts and linkages. As an example, refer to Figure 4- 
1. The satellite bus is the central concept. The motherboard architecture is another 
concept. The device which connects the two is the linkage. The linkage in this case is 
“has a”. This method ties the two concepts together into a meaningful structure. 

The team developed the concept map in Figure 4-1 by carefully evaluating the 
concepts and linkages suggested through the chief decision maker’s tasking statement. 
This graphic represented the design team’s interpretation of the decision maker’s problem. 
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Figure 4-1: Concept Map of Problem 

The use of the concept map provided many benefits. It helped the team 

understand how various factors affected the problem. The team immediately realized that 
the problem was highly complex. The concept map generated many questions the team 
needed answered before a concentrated approach to the solution could be given. The 
team began to question how the operations concept affected a satellite design. How 
would integration and launch processing occur? Was launch vehicle selection an area to 
be explored? Another question centered on what type of components were “off-the-shelf’ 
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and what reliability did they have. The team also wanted to know what effect orbit 
selection might have on vehicle life time. 

The concept map helped the team identify issues that needed to be considered 
when examining candidate solutions. The team began to question how much modularity is 
needed in a satellite bus design and whether modularity is necessarily good. Other 
questions focused on how much autonomy a satellite bus needs and what reliability is 
required for a one year life time. 

The use of the concept map was only a starting point. The team realized that 
much research was needed to fully understand the problem. Questions prompted through 
the use of the concept map were instrumental in identifying areas where research needed 
to be performed. These areas included researching similar projects, satellite subsystems, 
launch vehicles, satellite design concepts, command, communication and control 
architectures, orbital mechanics, and potential mission modules. The concept map offered 
yet another benefit. This representation of the problem provided a potential mechanism 
for the team and the decision maker to fully discuss what the problem was and what it was 
not. The definition of the problem was further enhanced by establishing system 
boundaries. 

4.4 System Boundary 

Since the system boundary defined the elements of the problem that could be 
controlled or manipulated, the team decided that the best way to narrow the focus and 
scope of the study was to refine this area. The boundaries were divided into two distinct 
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environments; an external environment and an internal environment. Items that existed in 


the external environment influenced the solution space for the problem, but were not items 
that the design team could control. These items were considered outside the team’s scope 
with respect to redesigning components or changing concepts of operation. Items 


contained within the internal environment were aspects that could be controlled by the 
design team and were subject to trade studies Figure 4-2 provides a graphical 
representation of the problem’s system boundaries. 



The external boundary was comprised of the following items: the launch vehicle, 
the payload, the satellite contractor, the mission operations concept, the space 
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environment, the constellation design, the storage and inventory concept, and the Air 

Force Satellite Control Network. Aspects of each element are described below. 

• The launch vehicle : The design team examined the system requirements for placing 
the vehicle into orbit. The team decided to use the Pegasus XL launch vehicle for this 
design study. Aspects of the launch vehicle that had an influence on the satellite bus 
design were launch preparation time, mass-to-orbit performance, satellite-to-launch 
vehicle integration constraints, and fairing constraints. Launch vehicle development 
and integration of launch vehicle stages were outside the realm of the design team’s 
control and were not subjected to trades or redesign. 

• The mission module : A number of different mission modules were examined. These 
included remote sensing payloads such as multispectral imaging (MSI) systems, 
synthetic aperture radar (SAR) systems, infrared (IR) systems, and laser designators. 
Specific mission modules were not designed by the team to be integrated onto the 
generic bus. The bus design was influenced by the mission module’s data 
storage/health and status requirements, thermal loading, power requirements, mission 
requirements, and required pointing accuracy’s. 

• The satellite contractor : A satellite company has a definite influence on the design 
when it comes to manufacturing the actual satellite bus. Additionally, different 
companies have different manufacturing processes. Due to the preliminary nature of 
the design study, the team considered items that would create manufacturing 
difficulties, but did not perform extensive research into actual satellite manufacturing. 
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• The mission operations concept : The methods the United States Air Force (USAF) 
employs to perform its satellite missions had an influence on the satellite design. The 
design team did not attempt to change or modify the way the USAF does business. 
However, understanding the constraints and requirements needed to perform satellite 
operations was a prerequisite for this design effort. 

• The space environment : This was the actual operating environment in which the 
satellite bus would perform its mission. It was important that the design team 
understood what effects space could have upon the satellite bus. The team had to 
design the vehicle in such a way that it accounted for the space environment. 

• The constellation design : The actual use of the vehicle and constellation deployment 
was left to the satellite user. The orbit choice and number of satellites to be placed 
into orbit will be contingent upon the user’s need. The team provided a satellite bus 
design that attempted to maximize its utility to the user. 

• The storage and inventory concept : It was taken as an assumption that the satellite 
and its components would be stored and maintained in an appropriate clean room 
environment while the satellite was on the ground. Therefore, the team did not design 
any aspects of the storage and inventory process. However, consideration was given 
to this storage and inventory process when design alternatives were developed. 

• The Air Force Satellite Control Network (AFSCNV Since compatibility with the 
AFSCN was required by the decision maker, aspects associated with this satellite 
control network had a major influence on the design. Satellite components such as 
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receivers and transmitters had to operate at Space Ground Link System (SGLS) 
frequencies. The team made no attempts to redesign any aspect of the AFSCN. 

Items contained within the internal environment included the satellite bus 
subsystems, the launch vehicle interface, and the mission module interface. Operational 
concepts directly related to the use of the bus were considered within the boundary of the 
system. The team had the freedom to modify concepts such as on-orbit command and 
control, mission module and launch integration, and sensor data processing. The team 
decided that the concept of having two different on-orbit command and control systems to 
the satellite was well within the scope of the bus design. 

4.5 Needs 

Revision were made to the needs. This was accomplished because the team 
wanted a clearer understanding of the problem. The categorized lists created in the first 
iteration only provided generalized groupings of the needs. A deeper understanding of the 
problem required more definition be given to the problems needs. It was believed that if a 
needs definition could be tied to the system’s boundaries or the decision maker’s views 
(Rooney, 1996), it would offer a better understanding of the problem. The refined needs 
definitions are provided below and incorporate the sponsor’s views or the system’s 
boundary considerations as appropriate. 

• Mass : The satellite design had to be optimized to support as many mission module 
types as possible. Mission modules with masses between 23 and 114 kilograms had to 
be supported and fit within the constraints of a Pegasus XL launch vehicle. It was 
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thought that better designs would provide more mass and volume to the mission 
module yet still supply ample power and interfaces. 

• Responsiveness : Possible design alternatives had to consider the rapid launch of a 
satellite constellation. The bus/mission module combination had to be easily integrated 
to meet the need for rapid deployability and tactical applications. 

• Sensors/mission modules : Different mission requirements were considered; i.e., 
electro-optical (EO), infra-red (IR), laser designators. 

• Pointing accuracy : The question of pointing accuracy had to be considered when 
trying to achieve 1 meter resolution during an imagery pass of 5-10 minutes per orbit. 

• Power : The satellite design had to support peak power requirements up to 1 kilowatts 
and average power requirements of 300-500 watts. 

• Orbital maintenance : The satellite had to operate at a minimal orbital altitude of 300 
kilometers for a mean mission duration of 12 months. 

• Telemetry- Tracking, and Command : Satellite design alternatives had to be compatible 
with the AFSCN. Data downlinks had to support near real-time transmission of 1 
meter resolution imagery data. Encryption and deception provisions were also 
required. 

• Data storage : Designs had to support on-board storage of up to 100 images. 

• Data Processing : Design alternatives had to support minimal on-board processing and 
data compression algorithms for transmission of images to ground station. 
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4.6 Alterables and Constraints 

Alterables were those elements of the system and its environment that could be 
controlled by the chief decision maker. The constraints were those items which could not 
be changed by the decision maker. The team had to manipulate the alterables to achieve a 
solution, provided the constraints were satisfied. The items contained within the internal 
environment were considered the alterables. The items in the external environment were 
constraints on the alternatives for the design study. 

4.7 Actors 

The actors were all the people and agencies who were involved with some aspect 
of the system or project. It was important to understand and consider the impact the 
system has on all actors. The principle actor for any project is the chief decision maker 
(CDM). The CDM generates the requirements and objectives for the system, and is the 
approving and implementing authority for the solution. The CDM for this project was 
LtCol James Rooney of Phillips Laboratory, Kirtland Air Force Base. The design team 
was comprised of the engineers and analysts who will work together to develop the 
system. This project’s design team consisted of space operations and systems engineering 
masters candidates at the Air Force Institute of Technology (AFIT). The team was 
advised by members of AFIT’s Department of Aeronautics/Astronautics. 

The eventual user of bus design was also an actor in this design study. This was 
the warfighter who depended on tactical space assets to wage effective information 
warfare. In order for the warfighter to receive his information, the project’s satellites 
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would be commanded and controlled by Air Force space operators. Air Force launch 
personnel would integrate the satellites to launch vehicles and launch them into low earth 
orbits. Prior to launch, mission modules would be integrated with their satellite busses by 
qualified personnel. Prior to being required for missions, ready-to-integrate busses would 
be stored and maintained. All personnel required to complete these activities were 
important actors in the development of this system, and their needs were considered. 

4.8 Mission Module Overview 

The problem involved with the design of a “generic” satellite bus is that, because 
the bus is to be generic, it cannot be designed to one specific payload or mission. It must 
support the requirements demanded by all foreseeable missions within the scope of the 
overall design. 

4.8.1 Background and Scope 

The payload or mission equipment of any spacecraft is generally considered to be 
that particular spacecraft’s reason for existing. The payload is, after all, comprised of the 
equipment which the spacecraft owners and users desire to employ (from the space 
vantage) for the collection or distribution of very specific mission information. 
Consequently, satellite designs in the past have always focused on this specialized 
equipment, functionally separating it from the rest of the vehicle (satellite bus). Within 
this paradigm, payloads tended to be as large, expensive, and/or as powerful or capable as 
possible. The bus was basically designed and built to support that particular payload (i.e., 
the bus was built up “around” the payload). Thus, because of the specific nature of a 
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spacecraft’s payload equipment, as well as owing to the fact that all satellites are basically 
manufactured by hand, individual satellites tended (and continue) to be unique. 

Similarities in design and equipment among satellites of the same constellation or “family” 
are more numerous, but even these satellites have been and continue to be dissimilar in 
some areas, due to the addition of features, change of specifications, or flight experience 
from earlier designs. All of these factors, in addition to the slow historical launch rate, 
tended to drive up costs. A ‘Vicious circle” of spiraling costs ensued and continues today, 
driving designers to build fewer, more reliable, more capable, and larger satellites. The 
larger vehicles compounded the launch availability problem due to the fact that larger 
boosters became necessary for the larger vehicles — larger boosters take longer and are 
more costly to integrate. 

Shifting equipment and design focus AWAY from the payload components forces 
a shift in the spacecraft design paradigm. It focuses on the vehicle itself, the bus, as a 
starting point for employment of special sensors or other equipment from space. In this 
paradigm, the payload simply becomes yet another “component” which must be integrated 
into the vehicle as a whole — the payload specializes or tailors a standard vehicle to a 
specific mission or purpose. This paradigm is analogous to a multi-role fighter aircraft 
being outfitted with a particular weapons load for the performance of a specific mission. 
The fighter is the “standard vehicle” which can then be used for a variety of missions. 

This particular paradigm requires the payload designer to produce payload equipment 
packages which can seamlessly interface with and “take a ride” on a satellite bus which has 
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already been designed (or built) and can provide all the payload support functions 
necessary. 

The aspects of the satellite-to-mission module interface which will be most 
important to the mission module designer will be mass, volume, power, and data storage 
budgets available for the mission module. These budgets will provide the mission module 
designer with limits within which the mission-specific equipment must operate. 

Similarly, the most important considerations for the bus design will be the support 
of those baseline power, mass, stability, pointing, data handling, data storage, and thermal 
isolation requirements necessary to accommodate all of the baseline mission module types. 
These types include applications spanning basic electro-optical radiometers, multispectral 
imagers, LASER/LIDAR systems, and synthetic aperture RADARs. These mission 
module types were chosen for their diversity and their applicability to tactical space 
applications. Because of the generic nature of this study, and due to the fact that 
specifications for military systems (within these categories) are either classified or 
unavailable at this time, estimates for mass, power, volume, and other specific 
requirements had to be generated from experience, remote sensing class notes, SMAD, 
and the few analogous commercial, scientific, and civilian applications available for 
inclusion. For purposes of this design study, however, which focuses on the design of a 
specific satellite bus (not the mission modules), lack of specificity of mission module 
designs will not impact the overall design of the bus. The purpose of a discussion of 
mission module requirements will provide, in many cases, valuable performance 
requirements to be met by the specific subsystems of the satellite bus (e.g., pointing 
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accuracy requirements will drive decisions made about attitude control system 
components). In all cases, extrapolation of estimates was conservatively overestimated in 
order to provide sufficient design margins. 

4,8.2 Specific Mission Module Types 

4.8.2.1 Electro-Optical Imaging (EO) 

The least expensive, lightest weight, lowest power, and probably the widest used 
payload type for tactical missions is the simple yet capable, high-resolution camera system. 
The military utility of this type of imagery dates back to the first days of placing observers 
in balloons and later placement of cameras in reconnaissance aircraft. The EO mission 
module is very closely constrained to a Sun-synchronous orbit for optimal orbit selection, 
due to the radiometric equipment’s dependence upon reflected sunlight for illumination of 
a target. 

The following table summarizes some estimated EO mission modules and their 
characteristics. For the EO mission module, a central wavelength of 0.5 microns is 
assumed, and ground resolution is calculated based on a 350 km circular orbit. 

Table 4-1: Electro-optical (EO) Mission Module Estimations 


Aperture 

(cm) 

Diffraction 

Resolution 

(mrad/m) 

Mass 

(kg) 

Volume 

(m3) 

Power 

(w) 

30 

2.03/0.71 

23 

0.035 

7.5 

40 

1.53/0.53 

41 

0.082 

10.0 

50 

1.22/0.43 

64 

0.158 

12.5 
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4.8.2.2 Multispectral Imaging (MSI) 


Advances in image processing as well as improvements in detector performance 
over the past few years have made MSI a high-demand payload. The MSI mission module 
uses several different arrays of detectors (CCD arrays), each optimized to detect a specific 
band of EM radiation. Image processing produces simultaneous images of a target area 
characterized at various regions of the EM spectrum. Intensity levels at specific 
wavelengths may indicate, through analysis, a particular activity, characteristic, or object 
within the field of view. By overlaying and comparing the levels of intensity at specific 
wavelengths from a single target, many characteristics of the target and subsequent target 
identification may be determined by comparing the received spectra to known spectra 
(predetermined spectra for specific substances — a particular type of vehicle paint, for 
instance). Due to its wider range of detectable radiation bands, the MSI mission module is 
not as closely constrained to the Sun-synchronous orbit, although this type of orbit is still 
very advantageous. Specific orbit selections for MSI mission modules will vary, in 
accordance with varying detector types and specific mission objectives. 

Physical characteristics for the MSI mission module are similar, but more massive 
and more power-hungry, than the EO mission module. MSI payload characteristics will 
vary according to specific design and performance requirements. 

Estimates for MSI mission modules and their vital characteristics are included in 
the following table. Resolutions are calculated from a 350 km circular orbit. 
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Table 4-2: Multispectral Imaging (MSI) Mission Module Estimations 


Aperture 

(cm) 

NIR (1.5pm) 
Diffraction 
Resolution 
(prad/m) 

MIR (4.0pm) 
Diffraction 
Resolution 
(prad/m) 

LWIR (10.0pm) 
Diffraction 
Resolution 
(prad/m) 

Mass 

(kg) 

Volume 

(m 3 ) 

Power 

(w) 

30 

6.1/2.135 

16.3/5.69 

40.7/14.23 

28.5 

0.039 

60.0 

40 

3.75/1.3125 

12.2/4.27 

30.5/10.68 

50.3 

0.089 

80.0 

50 

3.0/1.05 

9.76/3.42 

24.4/8.54 

78.7 

0.169 

100 


4.8.2.3 LASER/LIDAR Applications 

Using optics similar to the EO package (and in some “functionally dense” mission 
modules, the VERY same optics as the visible camera/detector), the LASER imaging 
payload adds a LASER head and power supply (LASER pump) in order to illuminate a 
target with a specific wavelength of EM radiation. These payloads can produce very 
accurate three-dimensional imagery, making them well-suited for topographical missions 
and atmospheric/meteorological (cloud system) observations. 

The following table summarizes some estimated LASER/LID AR mission modules 
and their characteristics. 


Table 4-3: LASER/LIDAR Mission Module Estimations 


Aperture (m) 

LASER Power (w) 

Mass (kg) 

Volume (m 3 ) 

Power (w) 

30 

300 

38.7 

0.044 

318 

40 

250 

56.7 

0.089 

274 
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4.8.2.4 Synthetic Aperture Radar (SAR) 


By far the payload with possibly the greatest potential tactical “payoff’ is the 
Synthetic Aperture RADAR or SAR mission module, which can produce (through 
intensive image processing) very high resolution images. SAR mission modules, like 
LASER-based mission modules, are active sensing systems and, as such, generally require 
an order of magnitude greater power to operate than passive systems (EO and MSI). Day 
and night, all-weather operations are possible with the SAR mission module, releasing it 
from a “most desired” orbit type. 

Some estimated SAR mission modules (with stowed antenna — launch 
configuration) are summarized in the following table. 


Table 4-4: Synthetic Aperture RADAR (SAR) Mission Module Estimations 


Antenna Dimensions (m x m) 

Mass (kg) 

Volume (m 3 ) 

Power (w) 

8.0 x 1.5 

78.4 

0.318 

800 

10.0x2.0 

86.5 

0.564 

450 


4.8.3 Generally Specified Mission Module Support Requirements 

Though the aforementioned mission module types are varied (not to mention those 
mission modules which may be further differentiated (based on specialized application) 
within a given general type), there are certain requirements on the bus which may be 
specified, allowing components in many of the spacecraft subsystems to be chosen for all 
candidate designs. The requirements specifiable through mission module consideration 
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include stabilization control, pointing accuracy, attitude knowledge, thermal isolation, 
operating power, data handling, data storage, and data down-link. 

All design requirements which the bus must meet will be driven by the most 
demanding mission module type in all cases. Furthermore, because of the lack of 
specificity of mission module designs, those driving design requirements must necessarily 
be interpreted as “ranges” of values, as opposed to exact quantities. The following table 
summarizes the requirements necessary for support of all mission module types. 


Table 4-5: Estimated Mission Module Support Requirements 


Bus Performance Criteria 

Mission Module Support Requirement 

Pointing Accuracy 

0.2-0.1 degrees or better 

Attitude Knowledge 

0.07-0.05 degrees or better 

Data Compression 

4:1 minimum 

Data Storage Capacity 

2Gbytes minimum; modular unit 

Data Handling Capacity 

150 Mbytes/s or better 

Thermal Environment 

thermally isolated from mission module 

Available Mission Power 

peak power from 500-900 watts 

Available Mission Launch Mass 

120 kg or better 

Available Mission Launch Volume 

0.6 m 3 or better 
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5. Value System Design 


5.1 Overview 

A systems engineering approach to the development of a system considers the 
values and objectives of the chief decision maker (CDM). The requirements and values 
expressed by the CDM must be expressed as an organized set of system objectives. This 
set of objectives should drive all design efforts, and it must serve as the standard by which 
alternative solutions are evaluated. Often, the established objectives are in conflict; that is, 
positive performance for one objective may imply negative performance for another. An 
example of this is the use of cutting-edge technology, which may deliver high performance 
while admitting higher cost and technological risk. The objectives must be organized in 
such a way that the engineer may judge alternative solutions against all the objectives, and 
perform trade-off analyses where necessary. 

Value system design translates CDM values into a hierarchy of objectives, where 
objectives flow down from the top level in a well-structured manner. Each bottom-level 
objective has a corresponding measure of effectiveness (MOE), by which the performance 
of that objective is measured. In addition, each objective is weighted, in terms of 
importance, relative to the other objectives at the same level. Based on the performance 
of each objective, and the priorities of those objectives, alternative solutions receive a 
utility score, which can be compared to the scores of other alternatives. In this way, the 
value system allows the engineer to analyze trade-offs between competing objectives. 
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Each bottom-level sub-objective has a unique measure of effectiveness. The ideal 
MOE is a natural scale which can be directly measured or computed, such as speed in 
meters per second. However, the true MOE is often difficult and impractical to obtain. 
This is especially true for studies which occur early in the life-cycle of a system, where 
modeling and testing is limited. In this case, two options are available (Clemen, 1996: 79). 
The first is to use a proxy measurement. The proxy should be closely related to the 
objective under consideration. The second option is to “construct an attribute scale for 
measuring achievement of the objective” (Clemen: 79). This requires the definition of 
levels of performance for the objective, with levels ranging from best to worst. 

Several of the MOEs for this study are actually combinations of proxy 
measurements and attribute scales. All attribute scales used for this study have six levels, 
from zero (worst) to five (best). It was felt that six levels provided enough detail to make 
intelligent judgments. 

The MOEs for each bottom level objective are given in section 5.2. The 
contributing factors that aided in the construction of attribute scales are explained in Vol- 
II. 

Although most of the MOEs are constructed attribute scales, future design efforts 
for this program must convert these to natural scales wherever possible. 

It should be noted that for several of the objectives, the evaluation of the 
performance of the alternative solutions proved to be challenging. Members of the team 
combined their knowledge and experience to rate the performance of such objectives. 
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5.2 Objectives 

The team determined that the overall objective of this study is to: 

“DEVELOP THE BEST STANDARDIZED BUS FOR A SMALL TACTICAL 
SATELLITE." 

It is important to understand what the words in this objective mean in order to prevent any 
misinterpretations between team members, advisors and the chief decision maker. The key 
words are defined below: 

1. STANDARDIZED: The most important idea of the study. All other objectives must 
support this. The idea is that the bus will support many different mission types. 

2. THE BEST: Implies an open-minded approach to developing the best system, free 
from the bias of favored technologies and approaches. 

3. SMALL: The satellite must be compatible with a light weight launch vehicle, such as 
the Pegasus or the Lockheed Martin Launch Vehicle. 

4. TACTICAL : The project statement emphasizes tactical missions and a short life. 

The set of objectives used for this study is intended to fully capture the values of 
the CDM. Thus, all of the objectives discussed below were used to guide the 
development of subsystem and system-level solutions. Throughout the design of the 
overall system, many trade-offs were performed at the system and subsystem levels, in an 
effort to form a reasonably sized solution space within which alternative system solutions 
could be evaluated. 
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The top-level objectives are shown in Figure 5-1. The following sections explain 


each objective. 


! Produce Best Standardized Bus Concept | 



Figure 5-1: Top-level objectives 


5.2.1 Minimize Cost 

The cost is made up of two main elements. The first element is monetary cost. 

The performance of each monetary cost objective may not be measured in actual dollars; 
for some objectives a proxy utility scale will describe the cost. For others, cost estimating 
relationships (CERs) may be used where such relationships are available. CERs yield a 
cost in dollars, but all such costs must be stated for the same year (i.e., FY96 dollars). 

The second main element of cost is time. 

There are 9 bottom level objectives and MOEs under the cost objective. 

0-1. Minimize Time to Full Rate Production ( MOE: attribute scale) 

• Minimize Monetary Cost 

0-2. Minimize Research, Development, Test and Engineering (RDT&E) Cost ( 
MOE: Cost estimating relationship) 

0-3. Minimize Bus Production Cost (MOE: Cost estimating relationship) 
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0-4. Minimize Retirement Cost (MOE: Attribute scale) 

• Minimize Operations Cost 

0-5. Minimize Cost of Telemetry, Tracking, and Commanding 
(MOE: Attribute scale) 

• Minimize Cost of Pre-Launch Operations 

0-6. Minimize Cost of Mission Module Integration and System 
Test (MOE: Attribute scale) 

0-7. Minimize Cost of Maintenance (MOE: Attribute scale) 
0-8. Minimize Cost of Storage, Handling, and Transportation 
(MOE: Attribute scale) 

0-9. Minimize Cost of Launch Integration and Test (MOE: 
Attribute scale) 

5.2.2 Maximize Tactical Responsiveness 

Modsat is intended for tactical applications, as has been stressed by the CDM. 
Thus, responsiveness is a primary objective. Modsat satellites must be able to respond 
quickly to rapidly generated needs and mission requirements. One major driver of 
responsiveness is the availability of a launch vehicle; however, it was assumed for this 
study that launch vehicles are continuously available. 

The bottom level objectives are: 

0-10. Minimize Preparation Time to Launch (MOE: Attribute scale) 

0-11. Minimize Data Latency (MOE: Attribute scale) 

0-12. Maximize Capability For Tactical Maneuvers (MOE: Attribute scale) 
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5.2.3 Maximize Availability 


A sound system design for Modsat must attempt to maximize on-orbit availability. 
The bus must endure both natural and man-made hazards. Natural hazards are considered 
under reliability, while man-made hazards are considered under survivability. 

0-13. Maximize Reliability (MOE: Attribute scale) 

0-14. Maximize Survivability ( MOE: Attribute scale) 

5.2.4 Minimize Program Risk 

Program risk refers to the potential for elements of the program to fail to come 
together as planned. Risk can be assessed in the areas of cost, schedule, and performance. 
0-15. Minimize Cost Risk (MOE: Attribute scale) 

0-16. Minimize Schedule Risk (MOE: Attribute scale) 

0-17. Minimize Performance Risk (MOE: Attribute scale) 

5.2.5 Maximize Mission Utility 

Mission utility refers to the ability of Modsat to accommodate a range of different 
mission modules. In other words, it is a way of quantifying how well the bus performs its 
role of being generic and standard. The larger the range of possible missions, the higher 
the mission utility. This objective was difficult to construct, since it is hard to envision 
how such utility can be measured. It was decided that mission utility is supported by the 
various aspects of spacecraft bus performance, such as pointing accuracy and available 
power. In other words, if more performance capability is built into the bus, more mission 
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types can be accommodated. Thus, several performance sub-objectives were adopted, in 
addition to the obvious desire to maximize the available weight and volume for the mission 
module. 

0-18. Maximize Pointing Accuracy (MOE: Degrees of pointing accuracy) 

0-19. Maximize Data Storage (MOE: Attribute scale) 

0-20. Maximize Average Mission Module Power (MOE: Watts of available average 
power) 

0-21. Maximize Allowable Mission Module Weight (MOE: Kilograms of available 
weight) 

0-22. Maximize Adaptability ( MOE: Attribute scale) 

0-23. Maximize Orbital Accuracy (MOE: Attribute scale) 

0-24. Maximize Data Down-link Rate ( MOE: Mbytes/sec) 

0-25. Maximize Peak Mission Module Power ( MOE: Watts of available peak power) 
0-26. Maximize Allowable Mission Module Volume( MOE: cm 3 of available volume) 
0-27. Minimize Thermal Transfer (MOE: Attribute scale) 

5.3 Utility Functions 

In order to provide overall utility scores for each competing system solution, all 
MOEs must be converted to a common utility scale. The team chose a scale from zero to 
one for convenience, but the endpoints of the scale could be any numbers. The translation 
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from MOE to utility for a given objective is referred to as the utility function of that 
objective. A utility function is essentially a model that represents the preferences of the 
CDM for an objective (Clemen: 473). Feedback from the CDM enables the analyst to 
determine how much utility to assign a given level of performance. 

Ideally, each objective would have a unique utility function that reflects the risk 
attitude of the CDM. However, in the absence of participation from the CDM, the team 
took a generalized approach. The validity of the results of this study could be improved 
with feedback from the CDM with regard to utility functions. 

5.4 Priority Weighting of The Objectives 

The objectives on the same level in the hierarchy were assigned priority weights, as 
shown in Figure 5-2. These weights were determined based on the results of a preference 
chart survey. This survey was completed by the CDM, members of the team, and other 
subject matter experts, with feedback from the CDM being more heavily weighted. The 
actual survey is attached as Appendix A. 
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Figure 5-2: Phase two objective hierarchy 
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From Figure 5-2, it is clear which objectives are more important than others in the 
current value system. It should be noted that this set of weights is a reflection of personal 
opinions, solicited at a certain time and under a given set of technological, political, and 
economic conditions. Major changes in any of these areas could cause the relative 
priorities to change. This potential for change does not present a significant problem, 
since the overall scoring function (see section 5.5) can easily be re-calculated with new 
weights. In fact, a sensitivity analysis was performed on the alternative solutions by 
varying the weights of each of the top-level objectives. 

A comparison of the priorities of the top-level objectives is shown in Figure 5-3. 
Tactical responsiveness is the highest-rated objective, while mission utility has the second 
highest priority. It is interesting to note that the cost objective received the lowest rating, 
as opposed to its prominence in most system studies. 
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Figure 5-3: Top-level objective weights 
5.5 Scoring Function 

The utility values and objective weights must be combined to form an overall 
utility function. This function yields an overall utility score for a given alternative 
solution, based on its performance of each objective and the relative importance of those 
objectives. Alternative system solutions can be compared by their overall utility scores. 

Since this study was intended to produce concept-exploration design 
characteristics, and not detailed design recommendations, the team decided to avoid 
modeling the interaction among the objective attributes. 
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5.6 Flexibility of the Value System 


Since the value system drives all design efforts, changes in any of the elements of 
the value system can lead to different results. The objectives, weights, and utility 
functions used for this study could be modified upon further engineering efforts. It was 
not the intent of the team to create a rigid, unchanging value structure, but rather to create 
a robust framework within which intelligent decisions could be made. Now that the 
framework exists, it can be modified according to the changing desires of the CDM and 
the analysts who conduct further research on this topic. 
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6. Tradeoffs 


6.1 System Level 

Many important tradeoffs were analyzed at the system and subsystem level, and 
several critical design decisions were made. The purpose of this section of the report is to 
document these tradeoffs and decisions. Throughout the system study, the team has 
encountered many variables and options. Some of these have remained as variables, to be 
specified as elements of alternative system solutions for judgment against the value system 
criteria. However, many design decisions were made during this study, in order to narrow 
the solution space to a reasonable set of alternatives. Thus, the Modsat bus concept 
gained its shape throughout the study, as key decisions have built on each other. These 
decisions were made after performing tradeoffs between the alternatives, judging each 
against the Modsat objectives and constraints. 

Much work was done at the subsystem level, and this is documented in section 4.5. 
This section discusses the system level tradeoffs. 

6.1.1 One Satellite Per Launch Vehicle 

Rather than attempt to design very small satellite buses for a multiple-payload 
launch package, the team chose to focus on one vehicle that will fill the payload bay of the 
chosen launch vehicle (LV). A key objective of the study is to allow for as much mission 
module capability as possible per bus. It would be inconsistent with this objective to force 
mission module designers to integrate with a microsat, or to make them spread their 
mission capability over a multiple-satellite configuration. 
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6.1.2 Launch Vehicle 


The team originally chose the Pegasus XL, from Orbital Sciences Corporation 
(OSC). This LV is common for small low earth orbit (LEO) satellites. It is attractive for 
several reasons, among them being the ability to respond rapidly to mission needs and the 
flexibility of launch integration and location. 

6.1.3 Basic Spacecraft Configuration 

Modsat requires three axes of pointing control, since it has articulated solar arrays 

(see section 6.5.6) and must accommodate nadir pointing mission modules. According to 

aerospace consultant Emery Reeves, 

“The spacecraft configuration must provide two axes of control for each 
item that is to be pointed. The spacecraft body has three axes so the body 
alone can satisfy one pointing requirement; for instance, one body axis (i.e., 
the yaw axis) can be pointed toward nadir by control about the other two 
axes (roll and pitch). It two items are to be pointed, then the spacecraft 
must be configured with at least one articulated joint between the two 
items. For illustration, a body mounted antenna can be pointed nadir by 
controlling two axes of body attitude. A solar array can then 
simultaneously be pointed toward the Sun by using the third body axis and 
providing a single solar array drive to control the solar array attitude 
relative to the body. ..3-axis-controlled spacecraft generally use articulated 
panels” (Reeves, 1992:297). 

Although two-axis systems are usually cheaper, lighter, and less complex than 
three-axis systems (Reeves, 1992:305), it was determined that the pointing requirements 
of both the solar arrays and the nadir pointing mission modules mandate the use of three- 
axis control. 
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6.1.4 Data Delivery Architecture 


The users in the field would like to have their mission data as rapidly as 
possible. By requirement, Modsat must have S-band SGLS (space to ground-link 
subsystem) antennas which are compatible with the AFSCN. The SGLS link is limited to 
a maximum data rate of 1.024 Mbits/sec. Any tactical, warfighting satellite would benefit 
greatly from having its own high data rate downlink antenna(s), in addition to the SGLS 
antennas. Thus, the design team acknowledged that almost all Modsat satellites would 
require a high data rate antenna in addition to the required SGLS antennas. It was 
decided by the team to avoid selecting and integrating a particular type of antenna. 

Rather, the mission planners will have the flexibility to choose antennas that suit their 
needs. Thus, all Modsat bus designs accounted for the placement of a high data rate 
package, whether in the bus itself (as a standardized add-on) or as part of the mission 
module. 

6.1.5 Adaptability and Modularity 

As mentioned in the Problem Definition section, the CDM desires Modsat to have 
a flexible, adaptable design, such that additional capability can inserted, or excess 
capability can be removed, depending on the needs of each mission module. A modular 
approach will be used, whereby all busses are manufactured with all foreseeable 
component options attached via removable interfaces. Of course, center of mass and 
attitude control constraints may preclude the removal of some excess components, 
depending on the characteristics of the mission module in question. 
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6.1.6 Maximum Capability 


The Modsat bus must accommodate a wide variety of mission modules, and must 
therefore cater to the most demanding customers. This implies that there will be excess 
capability on many missions. Some of this may be mitigated by the modular architecture 
discussed above, but certainly not all excess capability can be removed. Some built-in 
excess is unavoidable with a mandated, standardized interface. 

6.1.7 On-Board Propulsion 

Magnetic torquers are often used in place of the bulkier propellant-thruster 
configurations to reduce spacecraft momentum. However, magnetic torquers cannot 
perform AV maneuvers (Everett, 1996). In section 6.4, it will be shown that Modsat 
requires AV capability to maintain its altitude at LEO. Moreover, thrusters are required 
to perform tactical repositioning AV maneuvers, which may very well be required as part 
of Modsat’s tactical mission profile (see Problem Definition). 

6.1.8 Data Processing 

Most space sensor applications require some degree of processing of the mission 
data, prior to its transmission to the ground. In any given custom-built satellite, it is 
possible for such data to be handled by the main spacecraft processor, along with all of its 
other processing functions. However, each mission type has its own very unique 
processing requirements, and it would be impossible to satisfy all with one processor. In 
fact, many instruments have their own mini-computers. Thus, the team decided that 
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mission data processing must be performed by the mission module. However, data 
storage will be available in the bus processor, as stated in the requirements. 

6.1.9 The Bus-To-Mission Module Interface 

Another key part of this study is the specification of a standardized interface 
between the bus and all mission modules. This very issue has been addressed by the 
Aerospace Corporation, and the results are documented in “An Approach To Rapid 
Payload Integration: The Spacecraft-To-Payload Interface Guideline (SPIG), Version 1” 
(Aerospace Corporation, 1996). According to this document, “the SPIG is intended to 
serve as a core building block on which the payload-to-spacecraft interface can be 
designed.” 

In the production of the SPIG, much systems engineering work has been 
accomplished to suggest an optimum standardized interface. The team decided to use the 
SPIG interface in lieu of designing their own interface. 

6.2 Reliability Analysis 

This study was undertaken to determine, at a minimum, an optimal starting point 
for the cost vs. reliability tradeoff. Fault tolerance via three different subsystem 
redundancy levels (single-string, double-string, triple-string), and fault avoidance via three 
different component quality classes (commercial-grade. Class B, Class S) were compared. 
Educated assumptions were made regarding the relative costs of commercial. Class B, and 
Class S components. The cost assumptions were changed twice to determine the effect on 
the optimum cost/reliability option. A baseline cost of $30M, calculated from the Modsat 
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cost model, was used in the study. The failure data used was extracted from a study of 
over 300 spacecraft failures from the early 1960s to 1984, dividing failure rates by an 
"improvement factor" to account for advances in technology. 

The study showed that the optimum point to begin a detailed cost vs. reliability 
trade study was with a Class B, single-string spacecraft. Varying the cost assumption did 
not significantly affect the result. Double and triple-string spacecraft with commercial 
parts also fared well, but when the weight penalty associated with redundancy was 
considered. Class B/single-string stands apart. Optimality was determined by fitting a 
curve to the data and looking for the point(s) closest to the "knee" of the curve. An even 
more optimal starting point might be achieved by designing a spacecraft that is Class 
B/Class S and/or redundant where warranted (e.g. the Telemetry, Tracking, and 
Commanding subsystem). The availability of Class S and B components in an era of 
decreased government space and defense-related cuts, as well as the rapid growth in the 
quality of commercial-oriented components, was not quantified in this study. 


6.3 Launch Vehicle Considerations 

The sponsor’s guidance required the satellite bus to be within the Pegasus and 
Lockheed Martin Launch Vehicle (LMLV) weight class (Rooney, 1996). Orbital Science 
Corporation’s Pegasus XL was chosen as the baseline LV, based on its success and 
experience. The air-launched nature of the Pegasus offers a tactical advantage over other 
conventional ground-based LVs. The capability of being rapidly deployed and launched 
into any inclined Low Earth Orbits (LEO) from any latitude and longitude is another 
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distinct advantage of the Pegasus. More specifically, the Pegasus XL was chosen over 
the standard Pegasus vehicle because the XL version offers more mass-to-orbit 
performance. 

6.3.1 Pegasus XL 

The Pegasus XL is a winged, three-stage, solid rocket booster that weighs 
approximately 22,680 kg (50,000 lbm) and measures 16.9 m (55.4 ft) in length and 1.27 
m (50 in) in diameter. The rocket is lifted by a carrier aircraft, usually a Lockheed L- 
1011, to a level flight condition about 11,580 m (38.000 ft) and Mach 0.79 before it is 
released for launch (Orbital Science Corporation, 1993:2-1). 

There are two major Pegasus XL features that impose restrictions on potential 
satellite bus designs. One is the Pegasus XL mass-to-orbit performance capability; the 
other is the booster’s payload fairing dimensions. 

6.3.2 Mass-to-Orbit Performance 

An important characteristic of any launch vehicle is the amount of mass it can 
place into orbit. The mass that the Pegasus XL can deliver depends on the altitude and 
inclination of the desired orbit, and whether the booster uses an optional Hydrazine 
Auxiliary Propulsion System (HAPS, explained below). The mass-to-orbit performance 
capability for the Pegasus XL is provided in Figure 6-4. 
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Source: OSC, 1993:3-3 

Figure 6-4: Pegasus XL Performance Capability 


6.3.3 Payload Fairing 

Pegasus XL offers two payload interfaces: a 38 inch diameter interface plate and a 
23 inch diameter interface plate. Both of these interface plates can be used with or 
without HAPS. Figure 6-5 shows the payload fairing with the 38 inch interface. If this 
configuration is used with the optional HAPS, the spacecraft design will lose 14.65 inches 
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from the available 84.22 inch height. Figure 6-6 depicts the 23 inch configuration without 
HAPS. When the HAPS is used with the 23 inch interface, 4.2 inches are deducted from 
the 70.57 inch height. 



Source: OSC. 1993:5-3 


Figure 6-5: Payload Fairing with 38 inch Interface 
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Source: OSC, 1993:5-4 

Figure 6-6: Payload Fairing with 23 inch Interface 


6.3.4 Hydrazine Auxiliary Propulsion System 

The purpose of the HAPS is twofold. It improves orbital injection accuracy and 
increases mass-to-orbit capability for satellites placed into altitudes greater than 
approximately 600 kilometers. The inclusion of a HAPS adds weight to the LV and 
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mandates additional restrictions on the height, mass and volume of the spacecraft, in a 
trade for added accuracy and/or higher orbit insertion. It was decided that the vast 
majority, if not all, of the Modsat missions would not require orbital altitudes above 600 
kilometers. Additionally, orbital insertion accuracy is mission specific and depends on 
mass, targeted orbit, and the particular guidance strategy adopted for the mission (OSC, 
1993:3-5). Thus, the team decided to exclude the HAPS configuration from 
consideration. 

6.3.5 Other Considerations 

Many other characteristics of the Pegasus XL influenced and constrained the 
design effort, including: 

• Spacecraft center of mass location constraints 

• Spacecraft stiffness/vibrational frequency constraints 

• Spacecraft mass limitations due to critical shear stress at the LV interface 

• Axial and lateral loads during launch 

To ensure that the design alternatives do not violate the Pegasus XL constraints, 
launch vehicle compatibility testing was incorporated into the Modsat model through 3-D 
surface rendering visualization (see Volume HI). 
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6.4 Baseline Orbit and Allowable Launch Mass 


6.4.1 Baseline Orbit-Type 

Section 6.3 demonstrated that sun-synchronous orbits are the most weight 
restrictive orbits for a launch vehicle. Many Modsat missions may require a sun- 
synchronous orbit. Therefore, the bus should be light enough to allow for such missions. 
But in order to establish a baseline launch mass, a baseline orbital altitude must be 
determined. This altitude will not be dictated to mission planners; in reality, they have the 
latitude to select an appropriate orbit, provided their spacecraft meet the launch mass 
constraint. 

Nevertheless, the team needed a maximum mass limit for design purposes. Recall 
from Value System Design that one of the measures of effectiveness for this study is 
allowable mission module mass. For the baseline orbital altitude, this mass is the allowable 
launch mass less the mass of the bus. The challenge was to find the optimum sun- 
synchronous orbit for design, and therefore, the spacecraft mass limit. The optimum orbit 
is defined as that which maximizes the allowable launch mass. 

6.4.2 Mass to Altitude Tradeoff 

The mass-to-orbit performance of a launch vehicle decreases as the orbital altitude 
increases. Thus, lower altitudes are desirable for large payloads. However, as the orbital 
altitude decreases, the requirement for AV (thrust) to maintain altitude increases due to 
increased atmospheric drag. 
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Since AV is provided through the use of propellant, the amount of propellant on¬ 
board the spacecraft is proportional the AV required to maintain altitude. Thus, this 
analysis seeks to maximize the allowable launch mass for a sun-synchronous orbit, less the 
mass of the propellant reserved for altitude maintenance. Analysis shows that this mass 
increases with altitude, until 350 km. Beyond this, the AV requirement decreases but the 
allowable launch mass decreases dramatically. Thus, the baseline design altitude was 
chosen to be 350 km. At this altitude, approximately 308 kg can be launched into sun- 
synchronous orbit. 

6.5 Subsystem Tradeoffs 

Tradeoff analyses were performed at the subsystem level, in order to further 
narrow the solution space. The subsystems of Modsat are described below: 
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Table 6-1: Spacecraft Subsystems 


Subsystem 

Principal Functions 

Other Names 

Attitude Determination and 

Provides determination and 

Attitude Control System 

Control System (ADCS) 

control of attitude and orbit 
position, plus pointing of 
spacecraft and appendages 

(ACS), Guidance, 

Navigation and Control 
(GN&C) System, Control 
System 

Propulsion 

Provides thrust to adjust 
orbit and attitude, and to 
manage angular momentum 

Reaction Control System 
(RCS) 

Structures and Mechanisms 

Provides support structure, 
booster adapter, and moving 
parts 

Structure Subsystem 

Thermal Control 

Maintains equipment within 
allowed temperature ranges 

Environmental Control 

System 

Telemetry, Tracking and 
Command (TT&C) 

Communicates with ground 
and other spacecraft; 
spacecraft tracking 

Communication (Comm) 

Electrical Power System 
(EPS) 

Generates, stores, regulates, 
and distributes electric 
power 

Power 


Source: Reeves, 1992:287 

6.5.1 Attitude Determination and Control 

The purpose of the Attitude Determination and Control System (ADCS) is to (1) 
stabilize the spacecraft against both external and internal torques that would disturb its 
desired orientation, and (2) maneuver and point the spacecraft in response to commands. 
An ADCS must meet several stability and agility requirements, including pointing accuracy 
and satellite slewing rate. An ADCS must operate in several control modes, each of which 
is employed during the various phases of the satellite's mission, each having different 
requirements. Since normal operations and satellite slewing control modes are the most 
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common, they tend to be the requirements drivers. Defining the various control modes is 
the first step in designing an ADCS. 

The second step is selecting the particular type of the attitude control method. 
Control methods range from passive to active, spinning to three-axis stabilized, 
momentum-biased via constantly spinning rotors internal to the spacecraft, to zero- 
momentum biased (no spinning rotors). Modsat employs a three-axis stabilized system, 
which offers the greatest amount of stability. 

The next step in ADCS design is to quantify the disturbing torques the spacecraft 
will be subject to. Internal torques can be controlled through careful design. External 
torques must be quantified and compensated for. External torques generally have four 
sources: gravity-gradients, magnetic effects due to the Earth's magnetic field, solar 
radiation, and aerodynamics. At the low altitudes Modsat will operate in, disturbances due 
to aerodynamics outweigh the others by two to three orders of magnitude. Thus Modsat's 
ADCS is designed primarily against aerodynamics-based disturbances. 

Next, ADCS hardware must be selected. This includes attitude sensors (Sun 
sensors. Earth sensors, star sensors, inertial measurement units, magnetometers), and 
actuators (reaction wheels, momentum wheels, control-moment gyroscopes, magnetic 
torquers, thrusters). The sensor suite chosen for Modsat was an Earth sensor, a star 
sensor, and an EMU. This combination best satisfied the requirements of the different 
control modes. The actuators selected were thrusters and reaction wheels, which were 
best suited for Modsat's requirements and operating environment. 
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The final step in ADCS design is the design of the control algorithms that tie the 
sensors, actuators, and user-commands together. Although detailed control-law 
development requires a detailed knowledge of the satellite's predicted dynamic behavior 
(which itself requires detailed knowledge of the satellite's overall design), the designer can 
estimate the amount of control authority needed by considering the estimated worst-case 
disturbance together with the spacecraft's pointing accuracy and stability requirements. 


6.5.2 Propulsion 

The team did not set out to design new concepts in spacecraft propulsion, since a 
major emphasis has been placed on the use of competitively priced, proven technology. 
Instead, the design effort was limited to making use of currently available, off-the-shelf 
technology. 

The Modsat propulsion subsystem performs the following functions: 

• Orbital corrections. 

• Tactical re-deployment. 

• Acquisition of Sun, Earth, or star. 

• On-orbit back-up mode control with 3-axis stabilization. 

• Momentum management. 

• 3-axis control during AV. 
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6.5.2.1 Propulsion Options For Standard Satellite Bus Alternatives 


Propulsion subsystem options for Modsat were modeled and chosen with the aid 
of the Modsat computer model. The primary alterables for the propulsion subsystem are 
shown in Table 6-2. The design and placement of the Modsat propulsion subsystem is 
constrained primarily by the volume and weight limitations of the Pegasus Launch Vehicle. 


Table 6-2: Propulsion alterables 


Alterable Elements 

Possible Options 

Propulsion Type 

Liquid mono-propellant 

Liquid bi-propellant 

Pressure System 

Blow-down 

Regulated 

Propellant type 

Many 

Shape of Tanks 

Spherical 

Cylindrical 


6.5.2.2 Propulsion System Decisions 

The following decisions were made regarding the elements and configuration of 

the propulsion subsystem. 

1. The entire propulsion subsystem should reside on the bottom level of the satellite bus . 

• Launch vehicle considerations deem that the center of gravity of the spacecraft be as 
low as possible on the LV/spacecraft z-axis. 

• Since the specific mission modules that will be flown on Modsat are unknown, it is 
wise to keep any thrusters well below the bus-to-mission module interface. 

• The effects of thruster exhaust plume and other possible contamination from the 
propulsion system are reduced by locating it on a designated bottom plate. 
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• The propulsion subsystem does not fit in well with the modular nature of the bus, with 
its removable components and structural assemblies. It would be extremely difficult to 
locate any of the big components and systems anywhere other than on a fixed plate at 
the bottom of the bus. 

• The weight of pipes, vanes, valves, and the other propulsion plumbing equipment is 
reduced by consolidating the whole subsystem in one location. 

2. The propellant tanks should have a cylindrical shape . Cylindrical tanks maximize the 
use of the area on the bottom plate, and leave more volume to the other parts and 
pieces. 

3. The mono-propellant configuration was chosen as the Modsat standard . 

• Simplicity, cost, and reliability advantages over the bi-propellant configuration. 

• No significant difference in required tank volume between mono and bi-propellant 
configurations. 

4. The pressure feed system should be a blow-down system . 

• Modsat does not require the capability for high-level, long-duration thrust. A low- 
thrust, small propulsion system is adequate. 

• Since blow-down systems do not need regulators (and sometimes filters), they are 
simple and reliable (Sutton, 1992:326). 

5. Propellant: hydrazine 

6. Storage system: positive expulsion 

7. Commercial off-the-shelf thrusters will be used. 
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Thus, all of the major system alternatives for this study were designed with a 
mono-propellant (24%HN and 76% N 2 H 4 blend), blow-down pressure fed system with 
cylindrical tanks. 


6.5.2.3 Propulsion Alternatives 

After making the design decisions discussed above, the remaining propulsion 
alterable is the amount of propellant, which dictates the size of the cylindrical tanks. 

Although the mission requirements are uncertain, the idea behind the propellant 
alterable was to provide different amounts of AV capability. This capability must be 
divided among the spacecraft AV budget, which accounts for tactical maneuver capability, 
mission lifetime, retirement, and orbital accuracy. For a given amount of propellant, this 
budget must be managed by the user of Modsat. 

The amount of AV required to maintain the baseline orbital altitude or 350 km is 
62.2 m/s per year. At this altitude, the amount of A V required to make a one degree 
plane change is 134.3 m/s (Sackheim and others, 1992: back cover). It was assumed that 
momentum management will require 35-50 m/s of AV per year. The chosen propulsion 
alternatives for this study are shown in Table 6-3. 


Table 6-3: Propulsion system alternatives 


Alternative 

Altitude Keeping 
(m/s) 

Momentum 

Dumping 

(m/s) 

Inclination Change 
(m/s) / Degree 

Total A V 
(m/s) 

1 

62.2 

37.80 

- / 0 

100 

2 

62.2 

36.35 

201.45 / 1.5 

300 

3 

62.2 

52.05 

335.75 / 2.5 

450 
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Although the placement of thrusters was fixed, for each alternative the propellant 
tanks are located as near as possible to the center, in order to minimize the effect of 
diminishing propellant. 



Figure 6-7: The propulsion system 
6.5.3 Structures and Mechanisms 

The foundation of a spacecraft is its structures and mechanisms subsystem. 
Structures provides the framework for mounting the mission module and other 
subsystems; it must also connect to the launch vehicle. “Structures must [also] endure 
environments from manufacture to the end of the mission” (Doukas and others, 
1992:430). As with all satellite structure designs, the designer must review and adhere to 
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the mission requirements. In this study the mission requirement was to develop a low 
cost, “launch on need” tactical satellite bus capable of supporting various mission modules 
while launching off a Pegasus class booster. 

In support of a low-cost design, graphite and composite materials were not 
considered. Although graphite-epoxy composites provide “...extremely high stiffness-to- 
weight ratios...”, they are costly and “...often require a long, expensive development 
program to establish manufacturing processes” (Doukas and others, 1992:435-441). 
Because the use of composites increases the complexity of the structure and drives up 
construction costs, the use of other metallic alloys, such as aluminum, is more desirable. 
According to Doukas, et al, “Aluminum is relatively light-weight, strong, readily available, 
easy to machine, and low in raw material cost” (Doukas and others, 1992:435-441). 
Therefore, only aluminum alloys were considered for the main structure of Modsat. 

“Launch-on-need” implies the ability to launch within a few days, as opposed to 
several months, as with current launch schedules. Since the satellite bus must be able to 
support multiple mission modules, modular design will to be the most viable answer to a 
quick response launch. To further satisfy the “launch-on-need” requirement, the Modsat 
satellite bus allows for quick mission module and launch vehicle integration, easing the 
removal, replacement, and addition of the mission module and internal subassembly 
components. 

Since the Pegasus XL is Modsat’s primary launch vehicle, the team first concentrated 
its efforts on ensuring the satellite bus and mission module would fit within the Pegasus 
payload bay. 
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The next consideration in selecting a satellite structure was to select a geometric shape 


that best utilizes the payload bay’s volume and maximizes solar access (see Figure 6-8). 



Figure 6-8: Structure Shapes 

Except for the sphere, the geometric shapes are of similar construction, differing only 
in the number of sides, as depicted in Figure 6-9. One can see how increasing the number 
of sides utilizes more volume; however, there is a diminishing return to increasing the 
number of sides. 



Figure 6-9: Geometric Shapes with Similar Properties 

Although it appears that a cylindrical bus is the best geometric shape, the increased 

weight, limited access to subcomponents, and restricted solar wing placement in the 
stowed configuration make it a less desirable choice. Incidentally, Leritz and Palmer, in 
considering a geometric shape for their satellite design example, selected the cylinder and 
hexagon because they “distribute loads more uniformly” (Leritz and Palmer, 1995:490). 
From volume, surface area, and loading considerations, it seems likely that the best 
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Modsat structural design is a “polysat," an n-sided polygon. By varying the number sides, 
the best Modsat design can be found. Therefore, the “polysat” design became the main 
focus of structural modeling. 

Other considerations in the design of a satellite bus are the accessibility of internal 
subcomponents and the ease of mating the mission module to it. Although it is possible to 
space out structural members farther apart for cylindrical and spherical bus designs, the 
number of members still exceeds that of the “polysat” designs. Also, internal component 
accessibility from the side is more impeded than with the “polysat” designs. 

The next consideration of the team was to choose a satellite bus structure that best 
suits the goals for “low-cost” and ‘launch-on-need.” Figure 6-10 below depicts just a few 
possible structural designs. In considering these designs the team evaluated how each 
could be molded into a “polysat” design based on the following objectives: 

Modularity and Subcomponent Accessibility: How modular is the design and how 

accessible is it for removal and replacement of subassembly components? 

Materials Usage: Does this design minimize the use of materials in its construction? 

S tructural rigidity; What is the inherent strength of the structure? 

Manufacturing: The difficulty of constructing the structure 
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Figure 6-10: Satellite Bus Types 


Cage: The structure is made up of a variable number of sides with each comer 
constructed with a load bearing beam. This design is the closet to the “polysat” design 
discussed earlier. Although this design received high marks for modularity and 
manufacturing, it scored below average in material usage and structural rigidity. 

Truss: This structure mimics those used for future space constructions. This design 
scores above average in all categories except for modularity . 

Blocks: This design incorporates the bolting together of subassembly components. 
The block design is the strongest of all, but at the expense of added weight and 
machining. 

Shelf: Most satellite designs use the box frame with shelves to layer the placement of 
payload and subassembly components. This type of design received average scores for 
material usage and manufacturing, and below average scores for modularity and 
structural rigidity. 


72 





Drawer; This structure, a modified “Shelf 5 design, incorporates a pull-out and plug¬ 
in design. Although its modularity score improved, the drawers add extra weight and 
complexity to the design. 

Although it was determined that Modsat should have a “polysaf 5 structure, the best 
polysat configuration can only be found upon modeling the complete Modsat bus design. 
Second, the team reviewed both current and revolutionary designs to determine the best 
functional design. Both the “Cage” and the “Truss” scored well, but the “Truss” design 
will require additional harnesses and brackets to support subcomponent attachments. 
Therefore, the team decided to design Modsat with the “Cage” configuration, which best 
supports the “polysat” design. 


6.5.3,1 Polysat Design 

Since it was determined that the best shape for Modsat is a “polysat”, it is necessary to 
find the optimal number of sides to build the Modsat bus structure. 

Although the number of sides is a design variable that can be specified in the model, 
this number should be minimized. By doing so, more space is allowed between support 
beams, granting greater side access to the subcomponents. The other consideration is the 
solar panels. As the number of sides increases, so does the number of folds in the solar 
array structure (see Figure 6-11). This increases the complexity of the solar panel design 
and reduces the reliability of its structure. The main driver is to select the minimum 
number of sides to obtain the solar panel area necessary to meet power requirements. 
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Through extensive modeling the octagon was chosen as the baseline structure because it 
makes good use of the LV fairing volume while meeting power requirements. 


6.5.3.1.1 Solar Panels 

The requirement for large amounts of electrical power played an important part in the 
design of the Modsat structure. To meet the power supply goal of up to 500 watts, 
considerably large solar panels are necessary. Modeling for the electrical power 
subsystem (EPS) determined that up to seven square meters of solar array area would be 
required. Thus, the determination of the solar wing placement and deployment 
mechanisms proved to be a sizable challenge. 

Since the structural design focused on maximizing internal volume, the team 
discounted the use of a folded-wing configuration for the stowed arrays, due to its 
inefficient use of space within the launch vehicle fairing. The team also considered a 
deployment scheme similar to that used by Milstar, where the arrays spread out accordion- 
style from a small canister. Although this approach saves a great deal of space, it is very 
technologically complex and costly. Therefore, the team decided to wrap the solar array 
assemblies around the bus as shown below in Figure 6-11. 
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Figure 6-11: Top View of the Solar Panel Configuration During Launch 

In this configuration, the solar array assemblies must be constructed and hinged so as to 
fold around the polygon perimeter of the bus shown in Figure 6-11. This technique makes 
efficient use of the space within the launch vehicle fairing by placing the solar panels along 
the perimeter of the launch vehicle’s payload bay. Moreover, since the most severe launch 
loads are in the axial direction, the vertical placement of the arrays has structural 
advantages. 

It was decided that in order to simplify the design and construction of the solar array 
assemblies, they would not be allowed to extend in height beyond the curve in the Pegasus 
fairing. Any protrusion beyond this curve would require the use of special hinges and 
mechanisms, which would drive up cost and decrease the structural reliability of the 
assemblies. Therefore, the maximum height of the stowed solar arrays is dictated by the 
distance from the LV-to-spacecraft interface plane to the curve in the fairing. 
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6.5.4 Thermal Control 


6.5.4.1 Introduction 

Thermal design begins with defining its purpose. As the name implies, thermal 
design is concerned with constructing a “...thermal-controlsubsystem ... to maintain all 
elements of the spacecraft system within their temperature limits for all mission phases” 
(McMordie, 1992:409). In every satellite design, the designer must consider the thermal 
impacts due to the sun, the earth, and internal heat generation. Considering each of these 
thermal sources is important to ensuring the subcomponents within the mission module or 
satellite bus operate within their prescribed temperature ranges shown in Table 6-4. 


Table 6-4: Typical Spacecraft Component Design Temperatures 


Component or subsystem 

Operating Temperature 
(degrees in C) 

Survival Temperature 
(degrees in C) 

Digital electronics 

0 to 50 

-20 to 70 

Analog electronics 

0 to 40 

-20 to 70 

Batteries 

10 to 20 

0 to 35 

Infrared detectors 

-269 to-173 

-269 to 35 

Solid-state particle detectors 

-35 to 0 

-35 to 35 

Momentum wheels, motors, etc. 

Oto 50 

-20 to 70 

Solar panels 

-100 to 125 

-100 to 125 


Source: Wingate, 1994:433 


Just as the table suggests, the extent of thermal analysis depends on the thermal sensitivity 
of the satellite’s subcomponents. As pointed out by McMordie, the power system has the 
greatest impact on the thermal design because of the electrical energy being dissipated 
throughout the satellite and the tight operating temperature limits of the batteries 
(McMordie, 1992:411). 
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6.5A.2 Thermal Design and Modeling 

Thermal control can be accomplished either actively or passively, or both. The team 
decided from the start to maximize the use of passive systems to minimize cost, weight, 
and the power required of active systems (McMordie, 1992:413). Since “...preliminary 
mission design indicates that unmanned, low-Earth orbit spacecraft can be controlled 
passively”, active systems were not investigated in this study (McMordie, 1992:413). 
Therefore, passive systems such as thermal coatings, thermal insulation, and space 
radiators are ideal devices for meeting thermal constraints in a satellite design (McMordie, 
1992:411). 

6.5.4.3 Designing Thermal Interface Plate Protection 

To support the bus/mission module design discussed in the structure’s trade study, the 
team designed a thermal blanket constructed of woven insulation to be placed directly 
below the top interface plate, as shown in Figure 6-12. This blanket (under the mission 
module interface plate) will reduce the heat transfer between the bus (cage structure) and 
the mission module (on top of mission module interface plate) by restricting temperature 
changes between the two structures. 
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Figure 6-12: Thermal Protection of the Satellite Bus/Mission Module Interface 

This preliminary analysis concentrated on the 100 °C differential of a typical bus 
structure as the baseline. Depending on the temperature required by the mission module, 
the minimum thickness of the woven insulation to preclude a 15 degree Celsius change 
between either the plate or the mission module can be calculated (see calculations in 
Appendix C). For Modsat, the team designed a 4 cm thick interface blanket. 


6.5.5 Telemetry, Tracking, and Commanding/Command and Data Handling, and 
Communications 

Three different tradeoffs affected the Telemetry, Tracking, Commanding 
(TT&C)/Command and Data Handling (C&DH), and Communications Subsystem. The 
tradeoffs occurred in the areas of communication systems, command and data handling 
system, and the type of components to be used in the satellite bus design. 
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6.5.5.1 Communications 


Communications systems are very straight forward functions for a satellite. The 
system consists of equipment necessary to relay commands to the vehicle from the ground 
and to send health, status, and in some cases, payload (mission module) data from the 
satellite to the ground. The sponsor indicated that the bus communications system had to 
be compatible with the Air Force Satellite Control Network (AFSCN). The Space 
Ground Link System employed by the AFSCN imposed a limit on how much data could 
be transmitted to the ground. Since it was not uncommon for a satellite bus to employ 
two separate communications systems, the team decided that allowances had to be made 
to support a separate high data rate communications system. To provide flexibility for the 
user, the satellite could be included as part of the mission module design or a dedicated 
area on the satellite bus could be made available for a high data rate transceiver and 
antenna. A restriction was levied on the high data rate communications system. In 
addition to its primary function of downlinking mission module data, the system was 
required to interface with the satellite bus command and data handling system. 

6.5.5.2 Command and Data Handling 

The command and data handling system offered the team another area for 
tradeoffs. The conventional, or nominal, design of a command and data handling (C&DH) 
system requires that both the command and telemetry equipment, plus associated data 
lines, be hard-wired together. The command decoder, telemetry format unit, and 
controller are usually contained within a single unit called the command and telemetry 
unit. The C&DH functions operate under the direction of the controller. The controller 
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maintains the satellite timing and determines command priority if more than one 
commanding system is in use. Figure 6-13 shows the functional relationships for a 
nominal C&DH subsystem. 


S N 



Figure 6-13: Nominal Style of Command and Data Handling 


An alternate Command and Data Handling architecture involves the use of a 
Satellite Operating System (SOS) which enables an extremely broad range of modularity 
Using software, the main processor can perform the process of decryption/encryption, 
command controller functions, and data compression algorithms. Subsystem interfaces 
route through the Interrupt Request (IRQ) processor which handles traffic deconfliction 
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and prioritization. Instead of conventional hard-wired interfaces among subsystems, 
modular subsystems route their functional requests/needs through the central processor 
which prioritizes subsystem requirements in view of overall satellite operations. 
Subsequently, appropriate action is directed to the proper subsystem in a format 
understood by the modular subsystem. In essence, SOS provides an interface to allow 
vastly different subsystems to communicate to each other and work together through a 
baseline structure. Further advantage is gained by the ability to change SOS on the fly 
while the satellite is in orbit, through the uploading of new software to the central 
processor. A block diagram is shown in Figure 6-14: 



Figure 6-14: Proposed Style of Command and Data Handling 
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A subsystem design trade-off was performed between the nominal C&DH design 
and the Satellite Operating System. The Satellite Operating System was selected as the 
baseline for the satellite bus design. This system was selected over the conventional 
means because the SOS offers more advantageous characteristics. The SOS will be a 
lighter-weight design because software can replace some of the subsystem hardware. 

For example, software code can replace the command matrix board, the encryptor, and 
the decryptor hardware. SOS offers yet another advantage. SOS has a means for 
modifying the downlink of health and status data in a more user friendly-manner. 

Software code can permit the formatting of satellite telemetry data in such a manner that 
telemetry data can be accessed by ground users in much the same way that users access 
the internet. 

Another reason for the selection of the SOS is that it is modular in nature. The 
modular characteristics of the system allow for the easy addition or removal of 
components to the C&DH subsystem. By having the IRQ checks, the system could 
operate with or without the additional components. If a component is not connected to 
the bus, the SOS would be aware of this status. If a component is added, “driver” 
software would be resident within the SOS program that checks to see if the added 
component is available for operation. Another advantage of the selection of SOS is that 
the C&DH code could be modified while the spacecraft is in flight. While some spacecraft 
permit Attitude Control Subsystem modification, C&DH subsystem modification is not an 
option on most current satellite designs. 
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6.5.5.3 Component Selection 


Component selection was the last area where tradeoffs where performed for this 
subsystem. In order to select components for the design study, several companies were 
solicited for information. One of the goals of the study was to use commercial off the 
shelf components were possible. Components from other satellite programs, as well as the 
Jet Propulsion Laboratory (JPL) and the Naval Research Laboratory, provided the team 
with TT&C/C&DH component information. 

The Command and Data Handling components chosen for the generic satellite bus 
design were primarily rated on their performance-to-mass ratios. Cost was not a deciding 
factor. Discussions with satellite designers and engineers such as Richard Warner of 
Aero Astro, Dave Everett of NASA/Goddard Space Flight Center, and Joel Hagan of 
Phillips Laboratory’s MightySat Program, revealed that Command and Data Handling is 
one of the most critical subsystems on-board the satellite (Warner, 1996; Everett, 1996; 
Hagan, 1996). Without the proper functioning of this subsystem, the mission of the 
satellite would be lost. With this in mind, it was decided that only space-rated products 
should be used in the design of this subsystem. 

Other factors were considered in the selection of components. A requirement for 
the transceiver and antenna is that they must be compatible with the Space Ground Link 
System. Cincinnati Electronics provided information on a small transceiver that provided 
the correct frequencies for communicating with the Air Force Satellite Control Network. 
The amount of memory provided by a data storage device is also an important factor, 
since the satellite needs the capacity to store both mission module data and state of health 
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data. The Clementine Program provided a data storage device that provided 2 Gigabytes 
of data for a mass of only 3.4 kilograms. Other data storage devices considered were 
much more massive. Realizing that a Satellite Operating System architecture would 
require strong computing power, the team chose a radiation hardened, 32-bit, high speed 
Reduced Instruction Set Computer (RISC) architecture employing Very High Speed 
Integrated Circuit (VHSIC) technology. This computer was developed by Honeywell for 
the Ballistic Missile Defense Office. The associated controller and memory modules were 
developed under sponsorship of the Naval Research Laboratory. The computer and its 
associated controller were light weight and extremely powerful. 

Specific components were not selected for the high data rate communications 
system. As part of the design study, it was decided that the mission module developers 
would provide a transceiver and antenna for the satellite bus. This arrangement provides 
more flexibility for the mission module. Interface data, power, mass, and size 
requirements would be provided to the mission module developers to assure compatibility 
with the Satellite Operating System. In the concept of operations, the use of the Satellite 
Operating System would allow easier integration of a high data rate communications 
system. 
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6.5.6 Electrical Power 


6.5.6.1 Objectives 

An emphasis was placed on using readily available, relatively inexpensive 
components. EPS design also emphasized the use of proven components and 
architectures. In order to maximize the flexibility, an effort was made to accommodate 
modularity and ease of integration. 

The primary objective for EPS design is to provide sufficient power for the 
possible range of mission modules. The EPS must accommodate the most power-hungry 
applications planned to be flown on Modsat. Thus, a large amount of power must be 
available for the mission modules. However, not all configurations will require all the 
available power. A sound systems engineering approach must consider the impact of 
excess power (thermal effects, inefficient use of weight, etc.). 

6.5.6.2 Functional Allocation 

The EPS consists of four major functional areas, as shown in Figure 6-15: power 
source; energy storage; power distribution; and power regulation and control. A simple 
block diagram of the EPS is shown in Figure 6-16. 



Source: McDermott, 1992:391 

Figure 6-15: Electrical Power Subsystem Functions 
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Figure 6-16: EPS Block Diagram 

6.5.6.3 Power Source 

The power source generates electrical power for the spacecraft, supporting the 
electrical loads over many orbits. The power generation system of choice for Modsat is 
photovoltaic solar cells. Solar photovoltaics are the typical power source for LEO 
spacecraft. They are proven and widely available. Solar power is adequate for the 
intended mission, and lighter (in terms of specific power) than the other alternatives. 
Although there are cheaper sources, i.e., solar thermal dynamic and nuclear reaction, these 
alternatives require more mass. Nuclear reactors, furthermore, require a fuel that has 
limited availability, while solar energy is unlimited. Reactors are appropriate for 
applications requiring a large amount of power, but not for the loads and environment 
expected for a small, tactical LEO spacecraft such as Modsat. The same can be said of the 
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solar thermal dynamic alternative. The radioisotope alternative is very cost prohibitive. 
Given the strong emphasis on affordable access to LEO missions, the radioisotope 
alternative was ruled out. 

Solar cells must be mounted on solar array assemblies. The arrays should be 
planar and oriented toward the sun (Reeves, 1992:317). The power output is proportional 
to the amount of sunlight incident on the panels. Thus, the spacecraft should track and 
point the arrays for maximum incidence. 

Planar arrays may be body- or panel-mounted. The team decided to use panel- 
mounted solar arrays, on deployable booms, for Modsat. Following are reasons for this 
decision: 

• Panel-mounted arrays are usually mounted on deployable booms that rotate the panels 
for maximum incident sunlight. 

• Though body-mounted arrays reduce the requirement for tracking and pointing, they 
achieve less effective sun incidence angles and power conversion efficiencies than 
deployable panels. 

• There may not be enough available area on the body of the spacecraft for body- 
mounted arrays to provide the required power. > 

• With deployable booms, it is easier to place the panels away from payload instruments 
and other temperature sensitive subsystems that could be damaged from the highly 
variable temperature environment of solar cells. 
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On the other hand, panel-mounted arrays on booms add appendages to the 
spacecraft that add to the mechanical complexity and take up precious space within the 
launch vehicle fairing. 

The team recommends the modular solar array approach used by NASA’s Small 
Explorer (SMEX) Program (Everett, 1996), as well as Phillips Laboratory’s MightySat II 
spacecraft (Hagan, 1996), for the following reasons: 

• It is desirable to minimize the amount of excess power on Modsat. 

• It is more economical to limit the size of the solar array structure to the size necessary 
to produce the required power. 

• Flexibility in the design and integration of each spacecraft 

• With the modular approach, the engineers can build the solar array assemblies much 
later in the overall process of spacecraft construction (Everett, 1996). 

In the modular approach, a solar array is constructed of smaller solar modules. 
These modules are essentially small solar panels (8” by 16” for the SMEX program), 
which can be purchased in mass quantities (at reduced prices) long before assembly. Once 
the required power for the spacecraft is determined, the appropriate number of modules 
can be pulled from storage and integrated into a customized solar array assembly. This 
assembly consists mainly of a structural grid for inserting the solar modules. It must be 
built so as to conform to the chosen stowed/deployed configurations for the spacecraft. 

Although the modular solar array approach is recommended, the team decided to 
design each of the alternative Modsat concepts with maximum power for the sake of 
designing to the most difficult set of requirements. 
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During launch, the arrays will be wrapped around the bus in the stowed 
configuration. Thus, the amount of surface area provided by the bus, combined with the 
number of wraps, determines the power generation capability of the arrays, depending on 
the efficiency of the solar cells. 

Either silicon (Si) or gallium arsenide (GaAs) cells could be used on Modsat. 

Silicon is a clear choice for consideration. It is a proven, mature technology that has been 
the industry standard for years, although it is more bulky and less survivable than other 
materials. Gallium arsenide is also a proven technology, and is becoming more and more 
common on spacecraft. Although it is expensive compared to silicon, alternatives for 
which mass and volume become critical may require the use of gallium arsenide. 

In the EPS design portion of the Modsat model (see Volume III), one can choose 
either silicon or gallium arsenide as the solar cell material. However, throughout the 
design process, it became clear that silicon cells would not provide enough power per area 
to satisfy the requirement of the CDM (up to 500 watts), given the stowed configuration 
limitation on the size of the arrays. Thus, all of the Modsat alternatives were designed 
with gallium arsenide solar cells. 

The solar arrays must be sized to provide the required power at the end of the 
spacecraft life. Thus, the arrays must be large enough to account for the degradation that 
occurs over time. 

A final consideration for the solar arrays is the selection of solar array drive motors 
(SADMs). SADMs are necessary to mechanically rotate the solar array structures to 
achieve optimum angles of incidence with sunlight. Two SADMs are needed, one for 
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each solar array. For modeling purposes, representative SADMs were chosen from the Jet 
Propulsion Laboratory (JPL) Flight Hardware Survey, with the following characteristics: 

• Mass: 5 kg each. 

• Dimensions: Each is a cylinder, 10 cm diameter by 27 cm length. 

6.5.6.4 Energy Storage 

Since Modsat will not be generating power with a constant source, such as 
radioisotopes or nuclear reaction, a system must be designed to store energy for eclipse 
operations. The storage system must also be able to handle peak loads beyond the 
capability of the solar arrays, which are designed to handle average loads. 

The most common storage devices for LEO spacecraft are chemical batteries, 
known as secondary batteries since they discharge during eclipse and recharge in sunlight 
(McDermott, 1992:402). Other storage schemes are available, such as thermal storage, 
but they are far less common for LEO spacecraft than batteries. Some new approaches, 
such as flywheel storage, require much less weight than batteries. However, it was 
decided that new approaches with unproven technology would not be appropriate for the 
Modsat EPS. Space batteries are commonly used and widely available, and are therefore 
appropriate for Modsat energy storage. 

The two primary types of batteries in use today are nickel cadmium (NiCd) and 
nickel hydrogen (NiH 2 ) batteries. Nickel cadmium is a proven, easily available and 
comparatively cheap technology, but it delivers a relatively low energy density. Nickel 
hydrogen delivers more energy per kilogram than nickel cadmium, but it is more 
expensive. However, the cost objective received a lower priority than that of mission 
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utility. Although NiH 2 is a less mature technology for LEO applications (McDermott, 
1992:403), in recent years it has been used successfully in many spacecraft. The new 
common pressure vessel (CPV) design nickel hydrogen technology was successfully 
qualified on the Clementine mission in 1994 (Clementine Report). 

Since the CDM requested a peak power capability of 1000 watts, Modsat requires 
a great deal of battery capacity. The weight of the bus must be minimized; therefore, 
nickel hydrogen was preferred by the team. In fact, in an effort to drive down weight, the 
team decided to design all alternatives with two nickel hydrogen CPV batteries from 
Johnson Controls, the same battery flown on the Clementine mission. Characteristics of 
this battery are shown in Table 6-5. This design choice gives Modsat 30 amp-hours of 
battery capacity. 

Table 6-5: Characteristics of the Johnson Controls/Clementine NiH2 CPV Battery 


# of cells 

Capacity 

Energy density 

Dimensions. 

Weight 


(amp-hour) 

(W hr/kg) 

(cm) 

(kg) 

22 

15 

47.1 

50.8 x 13.4 x 13.4 

9.5 


Source: Clementine Report 


More flexible alternatives were examined, such as a modular scheme employing 
several low-capacity batteries. However, in keeping with the importance of minimizing 
weight and maximizing capability, modularity was sacrificed for a low weight, high power 
battery choice. 

The batteries were sized to handle: 

• Required power during eclipse 

• Peak power demands (supplementing the solar arrays) 
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6.5.6.5 Power Distribution 


The power distribution system consists of the cabling, fault protection, and power 
switching gear to turn power on and off to the spacecraft loads. A major focus in 
distribution system design is on keeping mass and power losses at a minimum while 
providing survivability, cost, reliability, and power quality. 

Since Modsat is intended to be a generic, standardized bus, the required load of 
the mission equipment is unknown until the mission need arises. Moreover, flexibility in 
configuration is a key value of the decision maker. Therefore, there is no fixed load 
profile for Modsat; the distribution system must take this into consideration. 

Mechanical relays are the clear choice for power switching, “because of their 
proven flight history, reliability, and low power dissipation” (McDermott, 1992:405). 
Solid-state relays may be the standard choice in the future, but presently they are an 
immature space technology. 

Decentralized distribution is the best approach for Modsat. It allows for a great 
deal of flexibility, thereby complementing a modular architecture. Each power-using 
component, including the mission module, must provide its own converter/regulator. The 
load nodes will be fixed, but the load users may be changed. This scheme obviates the 
need for customizing the distribution network for each mission application. 

The distribution system should include provisions for fault detection, isolation, and 
correction during testing (McDermott, 1992:406). Each fully integrated Modsat 
spacecraft must undergo extensive testing, especially since each many configurations will 
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be unique. A full set of fuses, placed in series with the power bus, will be required for 
fault testing (McDermott, 1992:407). 

The wiring can have up to 4% of the mass of the dry spacecraft (Reeves, 

1992:319). Since this is not a trivial amount, it is important to keep the distribution cables 
as short as possible. 

For modeling purposes, a power control unit (PCU) was chosen from JPL’s Flight 
Hardware Survey to represent the distribution system. This unit is a 24 x 16 x 20 cm box. 

6.5.6.6 Power Regulation and Control 

Power regulation must be considered for three key elements: controlling the solar 
array, regulating bus voltage, and charging the battery (McDermott, 1992:407). Solar 
array power must be controlled at the array to prevent battery overcharging and excessive 
spacecraft heating (McDermott, 1992:407). 

Two primary schemes are available: a peak-power tracker (PPT) and a direct- 
energy-transfer (DET) system (McDermott, 1992:407; Everett, 1996). A PPT is 
nondissipative; it extracts the exact amount of required power up to the array’s peak 
output. A PPT operates in series with the solar array, and uses 4-7% of the total power 
(McDermott, 1992:407). The DET system is dissipative because it shunts all power not 
used by the loads. A shunt regulator operates in parallel to the array and shunts the array 
current away when the loads or battery charging do not require the power (McDermott, 
1992:407). 

A DET system should be used as opposed to a PPT. The DET has fewer parts, 
lower mass, and higher total efficiency (McDermott, 1992:407). Moreover, given the use 
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of modular solar arrays, different Modsat missions will have different amounts of power 
being supplied. A simple shunt-regulated system, i.e., the DET system, would aid in the 
integration of such an architecture. 

An unregulated system should be used to control bus voltage, since regulation 
involves the dissipation of energy. This is inefficient and could potentially create heat in 
undesirable places. 

Batteries can be charged individually or in parallel. Parallel charging keeps the 
voltage of all batteries the same, but allows current and temperature to vary (McDermott, 
1992:409). Individual charging “optimizes the battery use by charging all the batteries to 
their own unique limits” (McDermott, 1992:409). 

Due to the emphasis on design flexibility, it seems advantageous to employ 
independent battery chargers. Their use aids in vehicle integration and maximizes the use 
of each battery (McDermott, 1992:409). A modular battery approach would be greatly 
facilitated by the use of independent charging, and greatly hampered by parallel charging 
(Everett, 1996). On the other hand, independent charging is more expensive and 
complicated than parallel charging (McDermott, 1992:409), and adds more weight. The 
current tradeoff of cost for mission utility led the team to recommend the independent 
charging approach. 

For modeling purposes, a shunt regulator was chosen from JPL’s Flight Hardware 
Survey to represent the regulation system. This unit is a 42 x 18 x 11 cm box. 
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6.6 Tradeoff Summary 


6.6.1 System Level 

• One satellite per launch vehicle 

• 3-axis stabilization 

• Modular component interfaces 

• On-board propulsion 

• Mission data storage 

• Spacecraft to Payload Interface Guideline (SPIG) interface 

6.6.2 Subsystem Level 

ATTITUDE DETERMINATION AND CONTROL 

• Inertial Measurement Unit 

• Star sensor 

• Earth sensor 

• Reaction wheels 
PROPULSION 

• Monopropellant configuration 

• Hydrazine blend propellant; 24% HN, 76% N 2 H 4 

• Blowdown pressure system 

• Positive expulsion fuel storage system 

• Bottom level location for the system 

• cylindrical tanks 
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• thrusters 


STRUCTURES 

• Octagon “cage” structures with “polysat” design 

• Modular mounting plates 
THERMAL 

• Interface thermal blanket between the mission module and satellite bus 
TTC/CDH 

• Satellite Operating System 

» software handles interrupt requests to collect telemetry and handle housekeeping 

• Internet communication format (TCP/IP) 

» JAVA compatible architecture enables user in field to access data via browser 
capable system 

» provides point-and-click environment to control satellite 
» encryption on demand with software plug-in modules 
EPS 

• Modular solar arrays on deployable, articulated booms 

• Solar arrays wrap around the bus in the stowed launch configuration 

• Gallium arsenide solar cells 

• NiH 2 common pressure vessel batteries 

• Decentralized, unregulated distribution 

• Shunt regulation; individual battery charging 


96 







7. Modeling 


Models play an important role in solving complex and multiple variable problems; 
as such, it is a critical element of systems engineering. To use systems engineering in 
designing a standardized tactical satellite bus, the team was faced with many variables and 
the relationships amongst them. Satellite design by its very nature is quite complex, and 
trying to account for every detail in this preliminary study is infeasible. Modeling enabled 
the team to approach the satellite design at a high level, focusing only on the major 
elements of the spacecraft. The team also used the model to test and evaluate the 
performance of the alternative solutions. 

Before considering modeling methods, it was important to revisit the problem 
definition, the objectives, and the measures of effectiveness (MOEs). This ensured the 
modeling effort was fully relevant to solving the problem, and within the framework of the 
objectives, the model would be able to evaluate the alternatives proposed to solve the 
problem. 

Once the basis for the model was understood, the team outlined the scope and type 
of model necessary to meet the objectives. Starting from a high level, the team determined 
the model must be highly integrated and compatible; the best way to satisfy this 
requirement was to use one program for all of the modeling. Once the model produced a 
satellite design, it would be important to perform some level of environmental and 
integration testing on it. Those designs meeting the testing and integration modeling 
elements required data analysis to assist in the final evaluation of how the alternatives 
ranked with each other. 
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Although these requirements for an integrated model appear easy to fulfill, they 
were not. The research conducted on the Internet found satellite software modeling still 
geared toward specific subsystems. Discussions with aerospace companies confirmed our 
findings, however, they mentioned how some companies are now using computer labs to 
bring subsystem experts together for satellite design sessions. To satisfy all the modeling 
requirements, it was necessary to develop an in-house satellite design model, using 
Matlab, a mathematical and graphics software package. 

To meet the “integrable, compatible, and adaptable” modeling requirement, 
Modsat (Modular Satellite) was constructed and built around a generic database structure 
format. By constructing all the subcomponents with the same generic database, 
compatibility among all the subcomponents was achieved. Once the subcomponent 
databases were constructed, they were combined into a single satellite database, thus 
ensuring the overall satellite design was totally integrable. Modsat satisfies the 
“adaptability” requirement by allowing the satellite designer to modify Modsat in three 
ways: 

• Correct, delete and/or expand the satellite database. 

• Make changes to the Modsat code substructure to incorporate more detailed 
analysis or changes in technology. 

• Tie into other external programs 

Using the modeling requirements listed above, Modsat development started with a 
high-level structure as shown in Figure 7-1. 
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Build satellite components and 
create a satellite database 


Check for subsystem overlap 
Check weight dimensions against 
launch vehicle constraints 
Calculate key satellite 


Check for subsystem interoperability 


Subject the satellite to various test 


Take test results and report how well 
the satellite met the MOEs 


Figure 7-1: Logical Flow of Modsat Model 


The Modsat model is geared toward sequential operation, starting from the top of 
the logic flow diagram and working down. Each step provides additional information 
about the satellite design, and at any given step the satellite design can be stopped to be 
modified or re-accomplished. 

Building satellite: Build subcomponent databases and combine them into one 
integrated satellite database. 

Test Satellite: Check the satellite database to ensure total satellite mass, center of 
mass, and sizing meet the launch vehicle constraints. If the satellite design fails any of 
these tests, the satellite design must be either scrapped or modified. 
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Initialize Operating System: Once the satellite design passes the “test” section, the 
satellite database is checked for subsystem interoperability such as power requirements. 
This section also calculates cost and reliability for the satellite design. 

Run Scenarios: This section subjects the satellite bus to launch and orbit 
environmental testing to determine its overall performance. 

Data Analysis: The satellite performance parameters are fed into data analysis 
either directly or indirectly, before being evaluated against a set of objectives. Each 
satellite design receives an overall utility score as well as an overall ranking with other 
designs. To complete the analysis and provide some variability in the results, sensitivity 
analysis can be performed by modifying and rescaling the top level objective weights. 

Although the Modsat model used first order assumptions and calculations, it 
proved to be an excellent systems engineering tool, allowing the team to design, test, and 
evaluate satellite designs. For a full description of the model, see Volume III. 
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8. System Synthesis 


8.1 Subsystem Baselines 

Each subsystem level study addressed the selection of individual components and 
the narrowing of requirements for each satellite subsystem. These components then 
became fixed in all of the candidate designs, yielding a baseline design on which alternative 
configurations could be based by varying the characteristics and/or configurations of the 
subsystems not fully determined by the tradeoff studies. This streamlined approach to 
subsystem and eventual system design facilitated the focusing of effort and the effective 
utilization of extensive satellite subsystem expertise by the more experienced team 
members. 

8.2 Alternative Design Descriptions 

The following discussion details the alternative designs evaluated using the Modsat 
computer modeling, design, and analysis software. To begin scoping the alternatives, all 
were designed to be compatible with the Pegasus XL/without HAPS configuration. Of 
the seven designs, six are based on the 38” interface, while the seventh is based on the 23” 
interface. The team judged early in the design process that the 23” interface configuration 
probably would not provide enough volume for Modsat because it reduces volume for the 
mission module and the size of the solar arrays. However, one alternative with this 
interface was generated for the sake of a complete analysis. 
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The designs fall into one of two categories. In the first category, there are three 
levels for component placement. The third level has a Supplemental Mission Adaptive 
Shelf, or “SMASH”, which is a large volume of space reserved for either a dedicated high 
data rate antenna and its transponder, or some other user-specified payload or mission- 
unique equipment. The second category has only two levels, reducing the overall bus 
height by not including a SMASH for additional mission equipment (such as a high data 
rate communications package). In the case of the second category designs, all mission- 
unique equipment would be placed entirely on the payload interface plate (very top of the 
bus). 

All designs fit a particular tactical profile, with tactical capability being determined 
by the amount of fuel on-board. Those designs with more fuel have more ability to make 
in plane or out of plane maneuvers, satellite altitude corrections, or other maneuvers. In¬ 
plane changes can be measured by AV; thus, total AV capability is the measure for how 
much a satellite can change its velocity. AV capability is directly proportional to the 
amount of fuel carried by the spacecraft. All of the designs have varying amounts of AV 
capability according to three sizes of propellant tanks carried by the spacecraft. There are 
three profiles for AV: max (450 m/s), mid (300 m/s), and low (100 m/s). These tactical 
profiles correspond to varying demands which may or may not be placed on the satellite 
during its mission. For a given category the three tactical profiles are essentially the same 
except for the size of the propellant tanks. Since the bottom level of the bus is reserved 
for propulsion, different tank sizes will raise or lower the bottom mounting plate, thus 
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increasing/decreasing the overall height of the satellite bus. The three tactical profiles and 
their capabilities are summarized in Table 8-1: 


Table 8-1: Tactical profiles 


MAXTAC 

Maximum AV capacity for orbit maintenance 

Up to 2.5 degrees of inclination change during mission 

MIDTAC 

Median AV capacity for orbit maintenance 

Up to 1.5 degrees of inclination change during mission 

LOWTAC 

Minimum AV capacity for orbit maintenance (one year) 


All designs have the same power supply capability (447 Watts average/1000 Watts 
peak), except for the 23” interface design, which has lower output (390 Watts avg, 950 
Watts peak) due to less area for the solar arrays. The seven designs generated as 
alternative solutions are as follows: 

• MAXTAC: Max tactical profile, with three component levels and SMASH 

• MIDTAC: Mid tactical profile, with three component levels and SMASH 

• LOWTAC: Low tactical profile, with three component levels and SMASH 

• MAXTAC-N: Max tactical profile, with two component levels and no SMASH 

• MIDTAC-N: Mid tactical profile, with two component levels and no SMASH 

• LOWTAC-N: Low tactical profile, with two component levels and no SMASH 

• MIDTAC-23: Mid tactical profile, with three component levels and SMASH; 23 inch 
interface 

The major characteristics of each design, including the height of each bus, were 
determined through modeling, and the results are shown in Table 8-2 . 
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Table 8-2: Major Design Characteristics 


Acronym 

SMASH 

Number of 
Levels 

AV 

(m/s) 

Interface 

(in) 

Bus Height 
(cm) 

MAXTAC 

Yes 

3 

450 

38” 

71 

MIDTAC 

Yes 

3 

300 

38” 

68 

LOWTAC 

Yes 

3 

100 

38” 

63 

MAXTAC-N 

No 

2 

450 

38” 

69 

MIDTAC-N 

No 

2 

300 

38” 

66 

LOWTAC-N 

No 

2 

100 

38” 

61 

MIDT AC-23 

Yes 

3 

300 

23” 

95.7 


8.3 Convergence of Individual Designs 

Most of the designs are very similar, except for the category and tactical profile 
differences; once an initial positioning of components is accomplished, the other designs 
simply incorporate the SMASH/no SMASH option and the tactical profile (propulsion) 
options. The design most divergent from the rest, of course, is the design based upon the 
Pegasus launch vehicle 23-inch interface. 

The process of design convergence begins with the physical constraints placed 
upon the satellite by the launch vehicle (in this case, the Pegasus ). Further, the main 
physical dimension constraining the bus is the diameter of the interface (38 inches for the 
first six designs, and 23 inches for the seventh). Starting with the interface plate of the 
launch vehicle and proceeding upwards with successive component “shelves”, placement 
of components may be initially estimated, spatially evaluated, and iteratively adjusted, until 
a reasonable, desirable arrangement of components solidifies into an integrated satellite 
design. The semi-cylindrical, shelf-like structure chosen for Modsat is conducive to this 


104 


















design convergence approach and facilitates the organization of components into 
“functional” groups. 


8.4 Component/Characteristic Listing 


The following list summarizes the set of characteristics and components that were 
chosen for Modsat. It should be clear that, to be consistent with the scope of this study, 
this is a high-level set of major components. The rationale behind the selection of these 
components is discussed in the Tradeoffs section of this report. Only those characteristics 
that were relevant to the integration of the overall design are included below. 

• Launch Vehicle Fairing Static Envelope (inside of which the spacecraft may be placed) 
Note: The Pegasus User’s Guide specifies a dynamic envelope of 46”. The team 
decided to use a more conservative static envelope due to the risk inherent in the use 
of the wrap-around solar array assemblies. This approach is used by the SMEX 
program (Everett, 1996). 

• Diameter: 44” « 112 cm 

• Height from spacecraft interface to curve in fairing: 111 cm 

• Structures and Mechanisms 

Note: All structural members are made of 7075-T6 aluminum, with a density of 
2,800 kg/m 3 . 

• Shape: Octagon 

• Structural cylindrical columns (8) 

- Dimensions: hollow; 4 cm outer diameter; 1.5 cm inner diameter; height 
varies with each design 

• LV interface plate 

- Diameter: 111.76 cm 

- Thickness: 1 cm 

• Component mounting plates (2 for with SMASH, 1 for no SMASH; note that 
the LV interface plate forms the bottom component plate) 

- Diameter: 87.26 cm 
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- Thickness: 0.2 cm 


• Center spine 

- Dimensions: 5 cm square; hollow; height varies with each design 
• Propulsion 

• Propellant tanks (4) 

- Dimensions: hollow cylinder; 2 tanks are 42 cm long, 2 are 33 cm long; 
diameter varies with tactical profile 

• Thrusters (6) 

- Dimensions: modeled as a cylinder; 6.6 cm diameter; 10.2 cm height 

• Valves (6) 

- Dimensions: modeled as a cylinder; 6.6 cm diameter; 8.2 cm height 


• ADCS 

• Reaction wheels (4) 

- Dimensions, cylinder; 25.5 cm diameter; 9 cm height 

- Mass: 5.1 kg each 

- Power requirement: 17 watts max 

• Reaction wheel electronics boxes (4) 

- Dimensions: box; 17.8 by 15.2 by 3.2 cm 

- Mass: 0.9 kg each 

• Earth sensor (head) 

- Dimensions: cylinder; 10.4 cm diameter; 16.3 cm length 

- Mass: 1.27 kg 

- Power requirement: 0.5 watts 

• Earth sensor (electronics) 

- Dimensions: box; 10.2 by 20.3 by 6.7 cm 

- Mass: 1.14 kg 

- Power requirement: 3.5 watts 

• Star sensor 

- Dimensions: cylinder; 13.5 cm diameter; 14.2 cm length 

- Mass: 2.5 kg 

- Power requirement: 10 watts 
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• Inertial Measurement Unit (IMU) 

- Dimensions: cylinder; 21.6 cm diameter; 13.3 cm height 

- Mass: 3.72 kg 

- Power requirement: 33 watts 

• EPS 

• Solar array panels (16) 

Note: Since the bus has an octagon shape, there are eight hinged panels per 
wrap around the bus. All configurations used two wraps, therefore all have 
16 panels. 

- Dimensions: box 

— Thickness: 4 cm 

-- Width: inner wrap panels are 36.14 cm wide; outer wrap panels are 
39.45 cm wide 

~ Height: varies with each design 

- Mass: varies with size of arrays 

• Batteries (2 NiH 2 ) 

- Dimensions: cylinder; 13.4 cm diameter; 50.8 cm length 

- Mass: 9.5 each 

- Capacity: 15 amp-hours each 

• Regulator 

- Dimensions: box; 42 by 18 by 11 cm 

- Mass: varies with power output 

• Power Control Unit (PCU) 

- Dimensions: box; 24 by 16 by 20 

- Mass: varies with power output 

• Solar Array Drive Motors (2 SADMs) 

- Dimensions: cylinder; 10 cm diameter; 27 cm length 

- Mass: 5 kg each 

• TT&C/CDH 

• Transceiver 

- Dimensions: box; 21 by 15 by 13 cm 

- Mass: 3.41 kg 

- Power requirement: 22 watts 

• SGLS Antennas (2) 

- Dimensions: cylinder; 4 cm diameter; 10.2 cm height 
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- Mass: 0.25 kg each 

• Central Processing Unit (CPU) 

- Dimensions: box; 5 by 22 by 15 

- Mass: 0.9 kg 

- Power requirement: 2.8 watts 

• Data Storage Unit 

- Dimensions: box; 13 by 13 by 13 

- Mass: 3.4 kg 

- Power requirement: 1 watt 


8.5 Baseline Design 

The MAXTAC bus (maximum propulsion, three shelves with SMASH) was 
chosen as the baseline upon which to conduct the detailed placement of components, The 
following discussion applies to the design of the MAXTAC. In section 8.6, the other 
alternatives will be discussed. The complete set of databases for each design is included 
with the modeling software (see Volume III). 

With the basic structure at hand, the team had to choose desired locations for the 
components. It was decided to place the components as shown in Table 8-3. 


Table 8-3: Component Placement 


Component Level 

Components 

1st 

Propulsion; one SGLS antenna 

2nd 

Batteries; PCU; Regulator; Reaction wheels 
and electronics; Earth sensor and electronics; 

Star sensor 

3rd 

IMU; TTC & CPU components; SADMs 


The rationale for locating the propulsion subsystem on the bottom level is 
documented in the Tradeoffs section of this report. It was decided to place a SGLS 
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antenna on the bottom level as well, such that the antenna would have a field of view 
through a hole in the LV interface plate. It was felt that an antenna was necessary in this 
location in order to communicate with Modsat prior to its full structural deployment. 

The team decided to place components on the second level in such a way as to 
keep the spacecraft center of mass as low as possible (due to LV considerations). Thus, 
the relatively massive batteries and reaction wheels were placed on the second level. In 
order to collocate as many subsystem components as possible, the regulator, CPU, 
reaction wheel electronics, earth sensor and electronics, and star sensor were placed on 
the second level as well. 

However, it was necessary to place the SADMs on the third level. The axis of the 
SADMs must be aligned with the axis of the solar array assemblies, which must in turn be 
located high enough to provide a balanced inertia matrix for the total spacecraft. In 
addition, the SADMs must be placed on the outer edge of the component plate, in order 
to mate with the extended solar array booms. The remaining TT&C/CPU components 
were placed on the third level. Nearly one half of the third level was reserved for the 
SMASH. The team modeled the use of this space with a hypothetical high data rate 
(HDR) package, consisting of an antenna and a transceiver. The antenna was modeled as 
a large cylinder, while the transceiver was chosen to be identical to the TT&C transceiver. 

The very top mounting surface of the bus (designated the “payload interface 
plate”) serves as the substructure for the mission modules. Several different types of 
mission modules may be evaluated with the various bus designs by using the Modsat 
computer model. For ease of evaluation for this design study, the mission modules are 
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oriented in the axial direction because the on-orbit attitude for the Modsat will have the 


payload interface plate pointing nadir. Future design efforts may introduce alternative 
orientations. 

Finally, it was necessary to keep the spacecraft center of mass as close as possible 
to its central axis. Thus, mass symmetry was a major factor in the placement of 
components. 

8.5.1 Structure 

Based upon the AV requirements given for the tactical profile desired, the height 
of the first component plate was set, and the initial positioning of components could 
commence. The MAXTAC structure is shown in Figure 8-2. 
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8.5.2 Propulsion 


Figure 8-3 shows the propulsion subsystem integrated into the structure. 



Figure 8-3: MAXTAC Propulsion Subsystem 

8.5.3 ADCS 

For the purpose of optimum three-axis control, the reaction wheels are canted at 
45 degree angles. The sensor components are placed at the outer edge of the component 
plate, such that they have a field of view through holes in the outer bus wall. The sensors 
face directions in which there are no solar arrays blocking the view. In Figure 8-4, the 
ADCS components are shown integrated into the structure. 
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Figure 8-4: MAXTACADCS 


8.5.4 EPS 

Due to the placement of the reaction wheels, the batteries hang from the bottom of 
the 2nd component plate. The regulator and CPU are placed symmetrically where space 
allows. The stowed and deployed EPS configurations are shown in Figure 8-5. 


112 



















Figure 8-5: MAXTACEPS 


8.5.5 TTC 

The SGLS antenna on the third component level is placed close to the outer edge 
of the bus. This antenna must be deployed on a boom with an appropriate mechanism. 
TT&C/CPU components are shown in Figure 8-6. 
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Figure 8-6: MAXTAC TT&C/CPU 

8.5.6 MAXTAC SMASH 

Figure 8-7 shows the top level of the bus, with the SMASH being utilized by a 
high data rate communications package. 



* 


Figure 8-7: MAXTAC SMASH 
































8.5.7 MAXTAC Composite 


The entire MAXTAC design is shown in Figure 8-8. The primary characteristics 
of MAXTAC are listed in Table 8-4. 



Figure 8-8: MAXTAC (deployed) 

Table 8-4: Primary Characteristics of MAXTAC 


Mass (kg) 

262.5 

Height of bus (cm) 

71 

Average Power (watts) 

447 

Peak Power (watts) 

1000 
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8.6 Variations on the Baseline 

8.6.1 MEDTAC 

The MEDTAC alternative is exactly the same as the MAXTAC bus, except that the 
bottom level is shorter due to the smaller propellant tanks. 



Figure 8-9: MEDTAC (deployed) 

Table 8-5: Primary Characteristics of MEDTAC 


Mass (kg) 

242.9 

Height of bus (cm) 

68 

Average Power (watts) 

447 

Peak Power (watts) 

1000 
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8.6.2 LOWTAC 


The LOWTAC bus is also the same as MAXTAC, but with an even shorter bottom 


level. 



Figure 8-10: LOWTAC (deployed) 

Table 8-6: Primary Characteristics of LOWTAC 


Mass (kg) 

215.7 

Height of bus (cm) 

63 

Average Power (watts) 

447 

Peak Power (watts) 

1000 


8.6.3 MAXTAC-N 

In the next three alternatives, the layout of the bottom level is the same as in the 
previous three alternatives. However, there is no SMASH. In fact, since the removal of 
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the SMASH space leaves only a few components on the top level, these components were 
relocated onto the second level to reduce the height of the bus. But the height of the 
second level was increased in order to fit all of components within. 



Figure 8-11: MAXTAC-N (deployed) 

Table 8-7: Primary Characteristics of MAXTAC-N 


Mass (kg) 

256.1 

Height of bus (cm) 

69 

Average Power (watts) 

447 

Peak Power (watts) 

1000 
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8.6.4 MIDTAC-N 



Figure 8-12: MEDTAC-N (deployed) 

Table 8-8: Primary Characteristics of MIDTAC-N 


Mass (kg) 

236.5 

Height of bus (cm) 

66 

Average Power (watts) 

447 

Peak Power (watts) 

1000 
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8.6.5 LOWTAC-N 



Figure 8-13: LOWTAC-N (deployed) 

Table 8-9: Primary Characteristics of LOWTAC-N 


Mass (kg) 

209.3 

Height of bus (cm) 

61 

Average Power (watts) 

447 

Peak Power (watts) 

1000 


8.6.6 MIDTAC-23 

Finally, a 23” LV interface version of Modsat was created simply to broaden the 
solution space somewhat. The MIDTAC platform was chosen, although any of the 
tactical profiles would have been appropriate. The MIDTAC-23 bus is exactly the same 
as the MIDTAC bus, except that it is placed higher in the LV due to the interface. 
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Figure 8-14: MIDTAC-23 (deployed) 

Table 8-10: Primary Characteristics of MIDTAC-23 


Mass (kg) 

292.8 

Height of bus (cm) 

95.7 

Average Power (watts) 

390 

Peak Power (watts) 

950 


8.7 Summary 

To primary characteristics of each alternative are summarized in, where 

1 = MAXTAC 

2 = MIDTAC 

3 = LOWTAC 

4 = MAXTAC-N 

5 = MIDTAC-N 

6 = LOWTAC-N 

7 = MIDTAC-23 









Table 8-11: Primary Characteristics of All Designs 


Characteristic 

1 

2 

3 

4 

5 

6 

7 

Mass (kg) 

262.5 

242.9 

215.7 

256.1 

236.5 

209.3 

292.8 

Height (cm) 

71 

68 

63 

69 

66 

61 

95.7 

Avg Power (W) 

447 

47 

447 

447 

447 

447 

390 

Peak Power (W) 

1000 

1000 

1000 

1000 

1000 

1000 

950 
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9. System Analysis 


This section discusses the evaluation of the alternative designs. The seven design 


alternatives are evaluated objective by objective. For objectives with natural measures of 


effectiveness, the performance value was obtained from the Modsat model. For objectives 
with attribute scale MOEs, the team rated the performance of each alternative against its 


attribute scale. 


The scoring results of the seven alternatives were extremely close, differing only by 


0.0467 in their final weighted score. This is not surprising, since the designs are not vastly 
different from one another. 


The main results for each alternative are presented below in Table 9-1 and Table 9- 
2. The scores listed under each main objective in Table 9-1 are weighted scores; that is, 
they are the result of multiplying the utility scores for a given objective by that objective’s 
weight. For a given alternative, the sum of the weighted scores for each main objective 
yields the overall utility score in the final column. 


Table 9-1: Weighted Scores: Standard Weights 


Weiaht 

0.1382 

0.3119 

0.1527 

0.1746 

0.2226 



Cost 

Responsiveness 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.07329 

0.2038 

0.1048 

0.1131 

0.1123 

0.6073 

MIDTAC 

0.09589 

0.1835 

0.1048 

0.1058 

0.1309 

0.6209 

LOWTAC 

0.1165 

0.1546 

0.1048 

0.06152 

0.151 

0.5884 

MAXTAC-N 

0.07378 

0.1962 

0.1054 

0.1169 

0.1134 

0.6057 

MIDTAC-N 

0.09354 

0.1763 

0.1054 

0.0947 

0.1296 

0.5995 

LOWTAC-N 

0.1098 

0.1469 

0.1054 

0.06507 

0.152 

0.5792 

MIDTAC-23 

0.09937 

0.18 

0.1048 

0.09085 

0.09914 

0.5742 


123 




























The final scores for each alternative are presented in again in Table 9-2, where the 
alternatives have been ranked. 


Table 9-2: Ranking of alternatives; standard weights 


1 

MIDTAC 

0.6209 

2 

MAXTAC 

0.6073 

3 

MAXTAC-N 

0.6057 

4 

MIDTAC-N 

0.5995 

5 

LOWTAC 

0.5884 

6 

LOWTAC-N 

0.5792 

7 

M1DTAC-23 

0.5742 


Considering the relative scale range of final utility values, the MIDTAC design 
scores significantly higher than the other alternatives. This comparison is clearly shown in 
Figure 9-1 below. 


Standard Weights 

0.5400 0.5600 0.5800 0.6000 0.6200 0.6400 

t- h —- 1 .«- 



Figure 9-1: Performance at Standard Weights 

Many factors combined to give the MIDTAC alternative the highest score. In the 

two highest-weighted objectives, tactical responsiveness and mission utility, the MIDTAC 
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design fared the best. In the remaining three lower-weighted objectives MIDTAC 
obtained average scores. The MAXTAC alternative also fared well, receiving the second 
highest score. This is attributed to MAXTAC’s high performance rating for the tactical 
responsiveness objective, which is the highest-weighted objective in this study. On the 
opposite end, the MEDTAC-23 alternative scored last, scoring average in four objectives 
and considerably low in the second highest weighted objective, mission utility. This is due 
to its usage of a great deal more of the launch vehicle fairing volume, as well as the 
reduced area available for solar arrays. Although MIDTAC-23 was last, LOWTAC-N was 
not that far behind, thus reminding the team that scoring well in higher weighted 
objectives is the key to a better overall score. 
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10. Decision Making 


The results of the previous chapter revealed that the MEDTAC alternative appears 
to be the best solution. The analysis discussed in this chapter was performed in order to 
demonstrate the sensitivity of the results to changes in the objective weights, due to 
shifting environmental factors. 

In this analysis, environmental scenarios were created in order to examine the 
effect of changes in the top-level objective weights. In each scenario, the weight of one of 
the objectives was increased to correspond with a certain environmental situation. The 
weights of the four remaining objectives were scaled down proportionally, so that all of 
the weights would still sum to one. With the new weights, the overall utility function was 
performed on each of the alternatives, and the results were recorded. In some cases, an 
alternative other than MEDTAC received the highest score. The scenarios are: 

1. Cost is twice as important as its original priority. 

2. Responsiveness is twice as important as its original priority. 

3. Risk is twice as important as its original priority. 

4. Availability is twice as important as its original priority. 

5. Utility is twice as important as its original priority. 

6. Cost has a full 50% of the sum of the priority weights for all the objectives (cost 
weight = 0.5). 

The rankings of the alternatives, for all scenarios, are shown below in Table 10-1. 
The MEDTAC alternative is the best solution. It scored in the top three in every scenario. 
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with three first place finishes, two second place finishes, and two third place finishes. The 
ranks for each alternative, summed over all the scenarios, are calculated in Table 10-2. 
These results further portray MIDTAC as the superior alternative. It is a well-rounded 
design that optimizes the tradeoffs between the objectives. Its performance in both the 
responsiveness and utility objectives, the two most critical attributes of the study, 
contributes to its high score. Note that MIDTAC scores well in both the responsiveness 
and utility scenarios, while the other alternatives fail to do so. 


Table 10-1: Sensitivity Analysis; All Environments 


Fterk 

Sbrtferrf 

CWx2 

FtepcnsiverESBx2 

Rskx2 

/Valsfci(ityx2 

UBIityx2 

33%QjeJ 

1 

MDT/C 

MDT/C 

mate 

MDT/C 

MW/ON 

LO/VT/C 

uw/c 

mu 

MWC 

icwr/c 

IWCN 

mate 

MDT/C 

MDT/C 

LQ/VT/CN 

wSk 

MMOI 

LOWT/CN 

MDT/C 

mw/cn 

mate 

LO/VT/CN 

MDT/C 

mm 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/CZ3 


UD/VT/C 

MDT/C23 

MDDCZ3 

LO/VT/C 

MDT/C-23 

MWCN 

MDT/CN 

m 

LQ/VT/CN 

IWC 

m/vnc 

UDAfflCN 

LCWT/C 

mate 

MW/CN 

Hi 

MDT/C23 

MW/CN 

LO/VT/CN 

mdt/C23 

i o/vt/cn 

MDT/C23 

mate 


Table 10-2: Sum of Rankings for the Alternatives 


Alternative 

Calculation 

Sum 

MAXTAC 

2+6+1+2+3+6+7 

27 

MIDTAC 

1+1+3+1+2+2+3 

13 

LOWTAC 

5+2+6+5+6+1+1 

26 

MAXTAC-N 

3+7+2+3+1+5+6 

27 

MIDTAC-N 

4+4+4+4+4+4+5 

29 

LOWTAC-N 

6+3+7+6+7+3+2 

34 

MIDT AC-23 

7+5+5+7+5+7+4 

40 
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11. Implementation 


This section is intended to aid the CDM in the implementation of the results of the 
Modsat study. As the purpose of the study was to perform high-level systems 
engineering, the continuation of the Modsat program will require much more detailed 
design effort. Moreover, the scope of this study was limited to the design of a spacecraft 
bus. Many factors and functions must eventually be considered and designed in support of 
Modsat operations. Recommendations from the team are included summarized as an 
overall “concept of operations,” and are discussed below. 

11.1 Continued Design Effort 

The systems engineering process is iterative and converging in nature. The scope 
of each iteration of the design process depends on the current stage within the life-cycle of 
the program. As the life-cycle progresses, the design process become more detailed. 
Eventually, the effort converges on an accepted detailed design. 

The design information included in this study is relevant for the first stage of the 
potential life-cycle of Modsat. In this stage, sometimes called “concept exploration,” the 
systems engineer “identifies all reasonable system alternatives that may satisfy the mission 
need and makes recommendations...; the [CDM] then selects those alternatives or 
concepts which meet [the] objectives” (Systems Engineering Management Guide, 1989:2- 
4). If the Modsat program is to progress further, the CDM must build on the concepts 
and recommendations included in this study. 
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In the next iteration of the design process, engineers must revisit the selection of 
components for Modsat, with a view toward optimizing the MEDTAC design. Interfaces 
must be designed, at the subsystem and component level. In particular, command, 
telemetry, power, and other signal flows must be examined. The design of software must 
begin, within the context of the modular satellite operating system recommended by this 
study. Prototype hardware should be developed to demonstrate the functionality of some 
of the unique aspects of Modsat, such as its cage structure, or its wrap-around modular 
solar array assemblies. 

At the system level, the mass properties (center of mass, inertia matrix, etc.) must 
be carefully examined for their effect on stability and control. Control logic should be 
developed to model the attitude control function of Modsat. Thermal characteristics 
should be modeled in more detail, and a thermal control system should be designed. 

The continued systems engineering effort on Modsat must incorporate concurrent 
engineering, wherein current engineering efforts reflect consideration of manufacturing, 
testing, logistics, operational support, etc. 

The items mentioned above are just a few of the many challenges awaiting the 
further design of Modsat. 

11.2 Concept of Operations (CONOPS) 

The design of a satellite comprises one of the many engineering efforts necessary 
for the operation of a complete space system architecture. The full architecture 
encompasses not only the design of the spacecraft and its mission-specific equipment, but 
also the ground segment (equipment and personnel), the launch segment (equipment and 
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personnel), and the information/ communications architecture (user interface with the 
system). 

11.2.1 Spacecraft Architecture 

Implementation of the small tactical satellite design (Tacsat) should take into 
account the fact that the “baseline” design is generally “over powered” (i.e., the baseline 
design provides too much average and peak power levels required for operation of most 
payloads). With this consideration in mind, application of an alternative design 
architecture (other than the “one size fits all” or “baseline” architecture) becomes desirable 
for optimization of the bus to the wide variety of mission modules, the majority of which 
do not require an average power of more than 400 watts or a peak power of over 800 
watts. The payloads which may require these high average and peak power loads are those 
of the active type (LASERs and S ARs), whereas passive sensors rarely require more than 
100 watts of power (peak — during a sensing pass). The optimization payoff can be 
measured in these cases with more available volume on the bus (for other equipment) and 
less spacecraft bus mass (increasing available mass for the mission module, or allowing a 
different orbit configuration — including a higher initial altitude). 

Given the fact that the solar arrays for MIDTAC are already a modular design 
tailorable to specific needs, and the fact that batteries already come in varying sizes for 
differing capacity requirements, the modular option should be the architecture chosen for 
initial implementation of the Modsat. Although actual operational configurations (stored 
and ready for use) for the Modsat will probably mimic the “family” architecture by 
including “pre-integrated” buses already tailored for either the low-power or high-power 
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mission modules (possibly already integrated with the some mission modules, as well), the 
modular design of the Modsat provides ultimate reconfigurability to suit changing needs. 

11.2.2 Launch Segment 

A small air-launched system provides maximum flexibility for the choice of initial 
orbit for small tactical spacecraft, because of the fact that any launch azimuth may be 
chosen. This capability also minimizes the time to reach a chosen target (i.e., the direct 
approach will be the fastest). The Pegasus air launched booster currently represents the 
only launcher in this category. The Taurus booster, while not air launched, is more 
powerful and was developed specifically for rapid deployment, integration, and launch 
from unimproved areas, making it also a good choice for the launch segment. 

The force structure recommended for employment of small tactical satellite 
designs consists of elements from the 30th, 45th, and 50th Space Wings (30th, 45th, and 
50th SW) working in concert. The 1st Tactical Space Launch Squadron (1st TSLS), 
based at Vandenberg AFB, CA (30th SW) would be responsible for westward (retrograde 
and Sun-synchronous) launches over the Pacific Ocean . Similarly the 2nd TSLS (45th 
SW, Patrick AFB, FL)would be responsible for flights east, over the Atlantic. The 19th 
Space Operations Squadron (19th SOPS), based at Falcon AFB, CO (50th SW) would 
have responsibility for Modsat launch and early orbit support, Modsat command and 
control. Tactical Network (TacNet) maintenance and support, and manning and operation 
of the Consolidated Tactical Space Control Center (CTSSC -- see below) for in-theatre 
operations support. Under the direction of a Launch Director, each of the Tactical Space 
Launch Squadrons would operate B-52 or other {Pegasus) carrier aircraft. In addition, a 
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spacecraft-to-mission module integration (SMI) crew, a spacecraft-to-launcher integration 
(SLI) crew, a loading crew, a flight and launch crew, an analysis crew and a launch 
(command and control) crew (under the direction of an Operations Director at the 19th 
SOPS and possibly deployed to a mobile or in-theatre site), would accomplish the 
integration, loading, flight (to launch location over either ocean), launch, and early orbit 
support for the Modsat mission. 


Tactical Space Launch (East Range/Atlantic) 



Figure 11-1: Proposed Organizational Structure for Tactical Spacelift 

(Eastern Range/Atlantic) 

The environment for the design study also assumes that a ready supply of 
launchers, satellite buses, and mission modules is on hand for both rapid response 
situations and space asset replenishment. Along with the supplies of hardware, other 
assumptions include ample logistics equipment (transports, “clean” environments, 
maintenance equipment, special tools, etc.), maintenance personnel, and storage facilities. 
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Specific personnel for each crew include enlisted-grade crew members and 
technicians/specialists led by officer-grade flight commanders and deputies (doubling as 
bus, mission module, and launch vehicle experts for their respective crews), and civilian 
engineering and analysis personnel (in-depth engineering-intensive positions should be 
made civilian contractor or GS billets to retain “corporate knowledge” on the systems). 


Tactical Space Launch (West Range/Pacific) 



Figure 11-2: Proposed Organizational Structure for Tactical Spacelift 

(Western Range/Pacific) 


11.2.3 Ground Segment and Information/Communications Architecture 

The main ground segment for the small tactical satellite should be an X, Ka, or Ku 
band receiving station, perhaps similar to the Air Force’s “Eagle Vision” mobile, in-theatre 
ground station, which receives mission data directly from both LANDSAT and SPOT 
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satellites, processes the imagery, and overlays the high-resolution visible-region imagery of 
SPOT with the multispectral imagery of LANDS AT. Multispectral imagery products 
from Eagle Vision have received rave reviews from operational and theater commanders 
(Veseley, 1996). Initial operations testing and/or proof of concept testing (for the new 
tactical satellites) could be set up to utilize current Eagle Vision equipment. 

This central receiving, processing, and distribution station, known as the 
Consolidated Tactical Space Control Center (CTSCC) would be manned and operated by 
crews from the 19th SOPS (50th SW) and would also incorporate an S band 
(SGLS/AFSCN compatible) commanding capability for spacecraft specific commanding. 
CTSSC terminal stations (including a permanent CTSSC at Falcon AFB, CO) would be 
deployed at several positions on the Earth to ensure full support for any and every theatre 
of operations. The CTSSC would be the centerpiece for a tactical space information 
network into which tactical users would input requests and receive information products. 
User requests/data updates would be transmitted via wireless ethemet protocols (adapted 
from currently existing internet protocols) carried through either MILSTAR MDR, 
Teledesic, Iridium, or a similar high data rate, global communications system. 

The process would be as follows: 

1) User signs on, and requests are encrypted and transmitted from a laptop or 
similar small computer in the field or from the cockpit. 

2) Requests are received, authenticated, and prioritized (set by the Theatre or 
Operational Commander) by CTSCC server. 
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3) CTSCC server queries (via intelligent agents) the types and availabilities of 
appropriate TACSATs (based on the type(s) of information requested by the user) as well 
as orbit predictions for those required assets which are available. 

4) The server calculates time over target, time to receive mission data, time to 
process, filter, and package, and time to transmit requested information to the user. 

5) If the requested information is available, the CTSSC server replies with the 
product; if not available, the CTSSC server replies with an estimated time of arrival (ETA) 
for the product, based on its calculations in 4). 

These tasks and the artificially intelligent systems and software required to 
accomplish them are possible with current computer and software technology and may be 
made functionally “modular” (in both hardware and software design) to ensure future 
upgrade capability. To make this system work well for an easily estimable “many” users, 
the communications systems employed and/or utilized will have to support the necessary 
bandwidth to successfully support the tactical user in a timely fashion; otherwise, the 
CTSCC’s tactical support capability will be degraded. Centralizing the processing power 
of this tactical space information system in the CTSSC (as opposed to performing the 
data-to-information processing on the satellites) allows more processing power to be 
utilized, allows easy upgrades to software, allows simpler troubleshooting of software, 
retains the satellites’ simplicity ~ both from the hardware and the software standpoints, 
retains central control authority for information dissemination, promotes optimal tasking 
of resources (again, due to centralized control and prioritization), simplifies 
communications to and from the satellites (multiple channels are unnecessary), and allows 
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future upgrades to the overall architecture to perhaps “evolve” into a system which 
incorporates more “on board” processing and direct downlinking to users. Having the 
information processed by the ground segment is the simpler, more powerful choice for 
current technology. 


Tactical Space Launch (Command and Control) 


50th SW 



An alternative to the (assumed baseline) ground-based CTSSC would be a 
dedicated command and control aircraft, or the CTSCC could be palletized and flown 
aboard a C-17 or C-5, further enhancing its mobility. 
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12. Future Technologies and Continuing Investigations 


The preliminary design for a small tactical spacecraft bus provides a solid 
foundation for further investigations as well as continued expansion of the Mod sat 
computer design model. Design efforts generated a tremendous amount of information in 
addition to producing the Modsat computer-based design tool and a design for a standard, 
tactically applicable satellite bus. Much of this information was not included within the 
formal system process either due to the planning horizon for the proposed design (five 
years) or because of the “nonessential” nature of much of the information (to the design). 
These topics nonetheless sparked many discussions during meetings and comprise an 
interesting set of ideas and technologies on which to base a possible future design study 
(or design studies). The design process also generated several concepts for future 
scientific research, operational analysis, and system design. 

12.1 Modsat Computer Model Enhancements 

The Modsat computer model, which was developed to aid in the design and 
evaluation of small tactical satellite designs, provides a foundation for further 
enhancements, additions, refinements, and detail. Modsat’s coding, though large in scope, 
is rather simple in style, and it is thoroughly documented internally. Future additions or 
modifications to the code may include: 

• more integration of orbit analysis features 

• additional mission module configurations and/or types 

• additional cost models 
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• more detailed component or subsystem modeling 

• larger libraries of selectable components 

• future technology modeling 

• more in-depth launch vehicle modeling and/or design 

• more detailed interface modeling 

Detailed discussion of the individual sections and functions (background, scope, 
functionality, limitation(s), and future feature suggestions) of the Modsat computer model 
can be found in Volume III in the Modeling section. 

12.2 Constellation Design 

Multiple satellites, carrying active sensors, may in the future be employed in 
concert as an “array” of sensors. The operational challenge of such a constellation can be 
solved either by maintaining relative satellite positions and attitudes to within close 
tolerances (within a few millimeters), or by maintaining extremely accurate position and 
orientation knowledge (to within a few millimeters). The second solution is the more 
feasible of the two, because satellites equipped with multiple GPS receivers can produce 
these knowledge products to within the accuracy necessary (NASA, 1995: sec.7, p.3), 
and with this knowledge ground-based computer processing can correct for discrepancies 
in received signals (between spacecraft). A constellation of this type would have the 
potential of creating an extremely large synthesized aperture; however, the processing 
power required for a constellation of more than two or three satellites would no doubt be 
tremendous and possibly prohibitive with current capabilities. 
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Further analysis may be performed regarding the types of orbits employed for 
tactical satellites. The primary orbit chosen as the baseline for this study was a Sun- 
synchronous orbit at an altitude of 350 kilometers. This orbit type has definite advantages 
for remote sensing and Earth resources missions; however, other orbits exist which may 
provide greater utility for specific missions. The highly eccentric Molniya orbits provide 
long dwell time, but at a geosynchronous altitude during that dwell time; this orbit type 
may be useful for tactically-applied communications satellites designed for short mission 
durations. “Walker” orbit parameters (Wertz, 1992: 189-192) provide a useful method 
for construction of constellations with specific coverage goals in mind. One example is 
that of multiple satellites being “staggered” in one or more specific orbital planes such 
that, as one satellite “sets “ on a target, the next satellite in line comes into view. 
Constellation design and optimization is a complex art. Space planners and designers may 
wish to examine the advantages and disadvantages of the coverages, dwell times, revisit 
times, and environmental stresses associated with various orbit types. 

12.3 Logistics and Operations 

There are logistical challenges involved with the transport, storage, and 
maintenance of a (large) supply of not only tactical satellite buses, but also mission 
modules (of multiple types), small launch vehicles, and support equipment (and support 
aircraft in the case of air-launched spacelift). Another possible (albeit novel) logistical 
and/or operational strategy study would be to investigate possible ways of recovering the 
satellites -- either by retrieval or reentry — and gauge their feasibility and utility in a 
tactical environment constrained by costs and the increasing desire to reuse hardware. 
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Further analysis may be performed on the actual missions and/or applications for 
the tactical satellite, not only on the sensing and support (of terrestrial forces) aspect of 
space based platforms, but also on the possible force application roles of such platforms. 

The air-launched ICBM test program of the 1970s and the current “ALT-Air” 
program sponsored by the Ballistic Missile Defense Organization (BMDO) have 
demonstrated the feasibility of a carrier aircraft-based, palletized launch scheme. In this 
scheme, a launch vehicle is transported inside the carrier aircraft, deployed off of an aft- 
ejected, parachute-assisted pallet with a stabilized drogue chute, and ignited. This launch 
scheme could be applied to a new launch system specifically designed for this purpose. 
Investigations could include adaptation of an existing system to this scheme (like the 
ICBM tests of twenty years ago). This transport environment has the potential of 
providing a much more benign environment (vibrational and thermal) for the launcher and 
spacecraft payload, as well as possibly supporting a “clean” environment (e.g., a “clean 
tent” such as used by the Pegasus) inside the aircraft itself during transport -- due to the 
fact that the interior of the aircraft is environmentally controllable. Additionally, regular 
loading crews would need no special training for handling the rocket pallet, since the pallet 
would be the same as any other pallet fitted for that particular aircraft. 

12.4 Mission Modules 

This design study focuses specific design determination efforts upon only the 
satellite bus; however, due to the particular design paradigm, the primary design standards 
imposed upon the mission module designer may be enumerated. Though the standard 
small tactical spacecraft bus will provide support for the mission modules, mission module 
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designers will be required to design “to the bus”, as opposed to the bus being built for the 
specific payload equipment. Analogous to the interface requirements to which underwing 
stores on a fighter must be designed, the mission modules must conform to certain 
electrical, mechanical, data protocol, telemetric, and software interfaces incorporated into 
the bus design. Many of the specifications for these interfaces will be provided by the 
SPIG (see Tradeoffs). 

Table 12-1 summarizes the generally specified requirements for the design of the 
various mission modules. 


Table 12-1: Mission Module Design Requirements 


Design Consideration 

Mission Module Design Requirement 

Mission Scope 

single-sensor type; narrow mission 
specification 

Mission Mass 

under 120 kg 

Mission Power 

average under 320 W 
peak under 820 W 

Mission Volume 

under 0.6 m 

High Data Rate Downlink 

must be integral if greater than SGLS rate is 
desired 

Data Storage Capacity 

must be integral if greater than 2Gbytes is 
desired (unless storage is modular) 

Mechanical Interface 

conform to SPIG 

Electrical Interface 

28 V regulated bus standard; conform to 
SPIG 

Telemetry/Software Interface 

compatibility with bus standard formatting; 
specialized mission software extensions (to 
SOS) must be integral 

Thermal Environment 

isolation from bus; specialized mission 
equipment integral 

Design Focus 

tactical; minimize testing time; minimize 
warmup time 
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The mission modules modeled in the Modsat computer model are necessarily 
“generic” in nature to provide both flexibility in design evaluation and a foundation on 
which more specific types may be modeled in both the current version and in future 
versions. 

Future operational analysis may focus on optimizing the functionality of different 
types of mission modules and putting together the most tactically useful, easily storable, 
quickly integratable, and technically feasible combination of mission modules for tactical 
space missions. 

A specific mission module for performance of a “LASER designator from space” 
role was not specifically addressed by the system design study, due to the number and 
variability of the many factors involved in the mission analysis for such a mission module, 
as well as the “experimental” nature of any such mission module if constructed with 
current technology. A mission module of this type may be roughly modeled, however, 
with the LASER/LEDAR mission module tools incorporated in the Modsat computer 
model. A future trade study on the design of such a mission module would require 
analysis of 1) illumination efficiency, power, and wavelength(s); 2) target 
reflectivity/signature in the given wavelength(s); 3) detector positioning (azimuth, 
elevation, and altitude), sensitivity in the given wavelength(s), field of view, signal to noise 
ratio, and velocity; and 4) possible adversarial countermeasures and spoofing. Finally, 
sizing of the mission module’s volume, mass, and power requirements may or may not 
make this application feasible for a small satellite application. Of course, a primary goal of 
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this type of research would be the determination of “payoffs” in costs, manpower, 
equipment, capability, and responsiveness that this type of system may or may not 
achieve. 

A similarly experimental application (and as worthy or more worthy of further 
investigation) being developed for LASERs is that of extremely high data rate 
communications systems. Many of the tradeoff factors and design considerations involved 
in the design of a LASER designation system are applicable to the design of a LASER- 
based communications system (i.e., power, sensitivity, positioning, signal to noise ratio, 
field of view, and, of course, atmospheric attenuation). 

12.4.1 Small Satellite Technologies “On the Horizon” 

Many novel and exciting (as well as very technically challenging) technologies 
promise to change the face of satellite design in the not so distant future. All of these 
technologies are expected to be developed within the next ten years. 

Flywheel Technology — Flywheels provide power and momentum storage through the 
utilization of kinetic energy storage. These structures represent potentially lighter weight 
and higher capacity than chemical-based batteries, with the added functionality of naturally 
stabilizing a spacecraft in (as do traditional momentum wheels). This “functional density” 
(in which one component performs more than one function) is a popular theme for small 
satellite design, and is already evident in most designs for spacecraft CPUs, as 
multifunctional microprocessors are becoming the norm for small satellites (Hively, 1996). 
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Lithium-Ion Batteries — These batteries provide vastly higher capacity than traditional 
and current technology chemical batteries (see Vol II, Tradeoffs, Electrical Power 
Subsystem). 

Inflatable Structures — This technology will allow smaller spacecraft buses to support 
much larger, more capable active sensors, such as those required for synthetic aperture 
RADAR. Current efforts are underway at NASA to produce electronically steerable, 
high-resolution RADARs for launch on small vehicles, but inflatable structure technology 
would significantly reduce payload mass and required payload fairing volume (scaling 
down required volume from “cubic feet” to volumes on the order of “cubic inches”), 
thereby freeing up space on the booster for other experiments (on the spacecraft) or other 
vehicles (within the fairing) (NASA, 1995). 

Global Positioning System (GPS) Applications - GPS promises to provide much better 
accuracy and more timely and autonomous orbital position prediction and tracking than 
current methods of ground tracking. Utilization of GPS will free up much of the 
overtaxed Air Force Satellite Control Network (AFSCN) from mundane “tracking” 
supports for the new vehicles equipped with GPS receivers. Experiments in the future will 
also include single vehicles equipped with multiple receivers, testing GPS capability to 
determine spacecraft attitude. If this application proves functional, it will relieve much of 
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the attitude control system requirements for attitude knowledge sensors, thereby further 
reducing spacecraft mass. 

“Toroidal” Propellant Tank — This propellant tank design was borne out of system 
synthesis efforts as a theoretically more efficient propellant tank packaging scheme, 
optimizing available volume within a spacecraft. 

Fourier Transform Hyperspectral Imaging — This imaging package under investigation 
at Phillips Lab represents a new paradigm in multispectral imaging -- spectral resolution 
approaching that of gas chromatography and/or spectrometers (i.e., evolution toward a 
“continuous spectral imaging system” paradigm) through the usage of Fourier Transform 
systems for spectral separation. Improved spectral resolution, lighter instrument weight, 
and more efficient transmission (than the current “best” method of dispersion gratings) is 
achieved through Fourier Transform separation (Hagan, 1996;Otten and others, 1995). 

Pulsed plasma thrusters -- These and other low-thrust, high specific impulse, non 
chemical propulsion systems will provide lower thrust, but more total delta-velocity 
capability (per unit mass) over the life of the satellite than chemical thrusters (Hagan, 
1996). Experiments utilizing PPTs are planned for the Phillips Lab’s MightySat program. 

Ka-Band Transmitter Experiment — Another experimental payload project for the 
Phillips Lab MightySat program, this phased array communications package will provide 








testing and validation of technologies expected to reduce the mass, moving parts, and 
spacecraft attitude adjustments required to track a signal from a communications ground 
station. It will also study high data rate modulation techniques. 

Small liquid-fueled booster -- Solid rocket motors (SRMs), while inexpensive and easily 
adaptable to small launch systems, are heavy, toxic, fragile, less flexible, and less reliable 
(in general) than liquid rocket-based launch systems. Phillips Lab and other research 
organizations (as well as some sectors in industry) are developing prototypes of a 
simplified “blow down” pressurized liquid-fueled rocket for use as a small launch system 
(Warner, 1996; Worden, 1996). This system incorporates propellant, oxidizer, and an 
inert pressurant (helium) to inject the propellant and oxidizer into the combustion 
chamber. This system can be built with few or no moving parts, and, by virtue of being 
“throttleable” the system’s performance can be fine-tuned and/or trimmed during flight (as 
opposed to a SRM, which may be vectorable, but not dynamically thrust-variable while in¬ 
flight), thereby increasing initial orbit accuracy. These types of simple, small rockets could 
eventually replace SRMs in most applications (e g., as an air-launched system). 
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13. Conclusions 


Although the individual products and ideas generated throughout this study may 
be individually worthy of merit, the three important results of this study folly characterize 
the synergism of the effort. The utilization of an adaptable (i.e., specific to the task at hand 
and the circumstances of the environment) System Design Process made all of the effort 
possible and productive. The generation of a feasible, value-added, “clean-sheet” 
MLDTAC design for a small tactical satellite bus provides a basis for further development 
of “tactical space” or “TacSpace” concepts. The construction of a generic and modular 
(i.e., robust, modifiable, expandable) Modsat Computer Design Model, though the 
greatest challenge of the effort, provides a useful, valuable design platform for use by both 
future researchers and students. 

13.1 Modsat Model 

The construction effort involved with the development of a folly integrated 
computer design and analysis tool for small satellites comprised a systematic design 
process in itself. As with the individual subsystem component choices, individual 
subsystem modeling sections formed along baseline component characteristics determined 
by the subsystem trade studies. The value system determined by the team formed the 
basis of the analysis section of the model. The Modsat modeling software package 
provides for analysis of physical characteristics, mission performance, and overall costs. 

The Modsat model provides a foundation for further analysis efforts. The 
underlying functions of the software may be modified or expanded according to a 
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particular user’s requirements and objectives. A vast array of different sizes, shapes, 
materials, and other characteristics may be modeled, based upon user input. The initial 
version of the model provides estimations which may be updated (through modification of 
the underlying code) with evolutions in space technology or changes in design philosophy. 
Aside from these more esoteric considerations, the software, of course, may be used for 
the analysis of small satellite designs other than those analyzed in this preliminary study. 
Using differently modeled components and differently modeled value systems, the Modsat 
modeling tool has the capability to produce a wide range of possible designs. 

13.2 Design Concept 

The MIDTAC spacecraft bus provides a generic design that may be further 
developed for specific applications or more completely engineered for actual production. 
The MJDTAC bus, as a complete system, has been designed to the extent that feasible bus 
enhancements may be easily explored and developed. As recommended by this system 
study, the expected implementation of the MIDTAC bus incorporates a modular power 
generation system to provide tailoring of power levels required by various mission 
modules. The actual design may also incorporate other modular and/or tailorable 
components or subsystems. 

The next step in the development of this bus design should be an engineering study 
of the interfaces required to integrate all of the individual satellite subsystems and 
components. While the MIDTAC design includes physical characteristics and a “working 
concept”, this design is only the first step in development process; it comprises the results 
of an initial “concept exploration” phase for a new space system. Concurrent engineering 
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studies concerning manufacturing, integration, and testing for the MIDTAC design must 
also be accomplished. Finally, mission modules must be designed for flight testing and 
operation on the MIDTAC bus. 


Figure 13-1: MIDTAC Bus and Vital Statistics 



Physical Characteristics/Capabilities: 

Mass: 243 kg 

Available Power (average/peak): 319/827 W (tailorable to mission) 

Available Mission Mass: 75 kg (350 km, sun-synch)/200 kg (350 km, 28.5 deg) 
Available Mission Volume: 0.7855 m 3 

Pointing Accuracy/Attitude Knowledge: 0.1 deg/0.05 deg (nominal) 

Data Storage: Modular 2Gbyte SSDR (tailorable to mission) 

Delta-velocity Capacity: 300m/s 

Subsystem Features: 

Mission Modules: SPIG interfaces, EO, MSI, LASER/LIDAR, SAR 

ADCS: three-axis stabilized, reaction wheels (4), star sensor, Earth sensor, IMU 

Propulsion: monopropellant thrusters (6), cylindrical tanks (4) 

Structural: octagonal “cage” structure, “3-level” shelf system, SMASH option 
EPS: NiH 2 batteries, modular GaAs solar arrays, decentralized distribution 
TT&C: SGLS compatible, 1024 kbps nominal downlink. Satellite Operating System 
(SOS), TCP/IP protocol 
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The MIDTAC design ultimately provides a solution to one portion of a much 
greater, underlying problem facing modem space efforts (military, scientific, and 
commercial). More responsive, less expensive, and more efficient access to space is an 
issue which requires new and innovative approaches to not only spacecraft design (the 
focus of this study), but also spacelift, command and control, and information processing 
and distribution. In addition to providing a tactically applicable satellite bus, the MIDTAC 
design will provide the Air Force with ready-to-fly space research platforms. The space 
environment will be more accessible to technology demonstrations, developmental 
payloads, and other space experiments by having these standard buses (with standard 
mission interfaces) readily available. The MIDTAC design essentially provides to the Air 
Force a standard vehicle -- putting the “horse” before the “cart” — on which it may more 
readily and effectively conduct space operations and technology development. MIDTAC 
will allow the Air Force to more quickly accumulate valuable “spaceflight time” and 
experience. Only with increased “hands on” experience in spaceflight and space 
operations will the Air Force fully evolve into its role as a “Spacepower”. MIDTAC 
provides the means to that end. 

13.3 System Process and Beyond 

The start of the system design began necessarily with a generalized, high-level 
treatment of the problem posed by the CDM: the generation of a “clean sheet” tactical 
satellite design for use as a “multirole” satellite, capable of supporting a wide variety of 
payload (mission module) types. This design should be easily and inexpensively produced 
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for the Air Force, smoothly integrated by a primarily “blue suit” special weapons crew, 
and quickly launched for either quick-response or asset-replenishment missions. Initial 
considerations involved the various high-level (nonspecific components) design and 
implementation approaches to this problem; further efforts evolved to focus efforts on 
creating the “baseline” or “point design” with which the original design approaches could 
be considered in combination. This combination of design (the MDDTAC) and approach 
(i.e., modularized components) produced an optimal solution. 

The (satellite) functional division of effort, in addition to the assignment of system 
process responsibilities among team members, was key to success. The convergence of 
the overall design and the development of the Modsat modeling software required expert 
knowledge of individual subsystems. Consideration of generic remote sensing mission 
modules provided baseline requirements for the bus design. The system, reliability, and 
subsystem trade studies narrowed the solution space for the bus design to a point where 
baseline designs could be generated. Effective coordination of the overall system design 
effort required central coordination for each of the system process phases: problem 
definition, value system design, system and subsystem design tradeoffs, system synthesis, 
modeling and optimization, decision making, and implementation. This approach not only 
allowed the systematic construction of a robust design and analysis tool, but also the 
synthesis of seven fully integrated, fully characterized designs which could then be 
thoroughly analyzed and evaluated. 

The basic validity and robustness of the process may be fully and objectively 
realized when considering the role of the CDM. Other than an initial, broad design 


151 



philosophy, the CDM provided little input. Faced with this “ill-posed” problem, the team 
created a process which allowed a “natural” evolution of objectives, focusing of efforts, 
convergence of designs, and, most importantly, solidification of goals. These goals 
included the construction of the Modsat model and the development of a “baseline” 
design. Modification of either the assumptions of the problem definition or the value 
system (based upon the preferences of the CDM) may yield vastly different results. This 
allows the adaptability of the process to other space system design projects. 

This process is unique, innovative, and goes beyond traditional system and satellite 
design approaches. Although Hall’s Process and the SMAD process were used as 
references and process “baselines”, these approaches ultimately proved unsuitable, due to 
the unusual design paradigm assumed by the team. The “mission module” is a concept 
wherein the payload equipment must be integrated to the satellite bus and conform to bus- 
constrained design parameters. This is a design paradigm unpopular within the aerospace 
industry, and runs contrary to the traditional approaches to spacecraft design prescribed by 
the SMAD process. Considering the stagnation of space efforts and the lack of relief from 
the high cost and low availability of space access, the pursuit of an alternative spacecraft 
design paradigm was reasonable, if not necessary. The team required, and ultimately 
developed, a process that was less dependent upon mission-derived design specifications 
and allowed more design freedom to consider the wide range of spacecraft design 
possibilities. 

Finally, the process is, unlike the SMAD process, synergistic in approach, and it 
epitomizes the concept of “functional density,” wherein the process served many purposes 
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simultaneously. The research involved in the subsystem trade studies produced the 
component data for use in the modeling tool, narrowed the scope of subsystem design 
choices, and refined the design objectives and value system. The iterative process of the 
synthesis of individual designs solidified design alternatives and also refined the model. 
The ultimate results of the development and application of this process resonate beyond 
the generation of the MIDTAC design and the development of the Modsat model. The 
results of this study show that, as a solution to the “space access” problem, an alternative 
to the current design paradigm (i.e., “generic” versus “specific”) is not only feasible but 
desirable. This study, its process, and its products set the standards of creativity, 
innovativeness, adaptability, and robustness for future spacecraft design efforts. The 
Modsat design team has set the bold example that others will follow. 
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